Problem of accessing Oracle DS in JBOSS from a stand-alone J

[guha_gourab]

Hello,

I am trying to access Oracle data source in Jboss from a stand-alone java program. For doing this I have done the following:

(1) Copied the oracle driver (classes12.jar) in server\default\lib directory of
JBOSS_HOME.

(2) Copied the oracle-ds.xml file from docs\examples\jca directory of JBOSS_HOME to
server\default\deploy of JBOSS_HOME.

In this file I have changed the connection URL.

(3) Next I have changed the default standardjaws.xml. I have changed the data source
name and its type-mapping to Oracle8.

(4) I have changed standardjbosscmp-jdbc.xml file also.

(5) I have put an entry in login-config.xml file also.

The code that I used to access the JNDI name for the data source is follows

public class JNDIServiceLocator
{
private static InitialContext intContex =null;

static
{
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY , "org.jnp.interfaces.NamingContextFactory");
env.put(Context.PROVIDER_URL , "jnp://localhost:1099");
env.put("java.naming.rmi.security.manager", "yes");
env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming");
try
{
intContex = new InitialContext(env);
System.out.println("Created the context ....");
}
catch(Exception e)
{
e.printStackTrace();
}
}

public static void main(String[] args)
{
try
{
intContex.lookup("java:/OracleDS");
}
catch (NamingException e)
{
e.printStackTrace();
}
}
}

Now I am getting the following exception

Created the context ....
javax.naming.NameNotFoundException: OracleDS not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:503)
at org.jnp.server.NamingServer.getObject(NamingServer.java:509)
at org.jnp.server.NamingServer.lookup(NamingServer.java:282)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:530)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:509)
at javax.naming.InitialContext.lookup(Unknown Source)
at JNDIServiceLocator.main(JNDIServiceLocator.java:33)


Can anybody give me any guide line regarding this problem.

Regards,
Gourab

[weston.price]

From the FAQ

http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanIAccessADataSourceFromAClient

[scottlong]

There are a few entries on the wiki that describe accessing JBoss datasource remotely via JNDI from external JVMs. They all describe this capability, experimental, not recommended, etc.

e.g. this one: http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanIAccessADataSourceFromAClient says:

Note: Exposing a Datasource remotely is NOT recommended.

and this one: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources says:

JBoss does not recommend using this feature on a production environment.

The one specific risk listed is that if the client dies (or fails to close connections), it will cause a connection leak. JBoss is not going to try and detect the client's death and proactively clean up for the client.

This makes sense, but are there other risks of using this remote datasource capability?

I am talking in terms of JBoss 4.0.5.

thanks!
- scott

[adrian.brock]

"scottlong" wrote:

This makes sense, but are there other risks of using this remote datasource capability?

Some risks, but mostly just anti-patterns (even if you ignore the crappy implementation
in JBoss4 - e.g. no leasing of connections so faulty clients can leak connections)

* Security - this is essentially a JDBC tunnel (remote client --> . --> database)
* DOS - Client gets a connection and never returns it (deliberately) eventually leading to
connection pool exhaustion
* Inefficiency - using a pooled connection remotely is not efficient, co-locate the business logic with the pool (or establish the pool on the remote client)
* No transaction enlistment - the remote connection does not take part in any transaction context established on the client - even a UserTransaction
* etc.

[scottlong]

Thanks very much Adrian.

If i might ask one more question... regarding:

the remote connection does not take part in any transaction context established on the client

... does this mean that even direct calls to Connection.commit() and Connection.rollback(), or possibly Connection.setAutoCommit() might not be propagated to the "real" JDBC connection held in JBoss? Or is the transaction context that the client cannot take part in limited to true "JTA" type transactions, UserTransaction, etc.?

[adrian.brock]

"scottlong" wrote:
Thanks very much Adrian.

If i might ask one more question... regarding:

the remote connection does not take part in any transaction context established on the client

... does this mean that even direct calls to Connection.commit() and Connection.rollback(), or possibly Connection.setAutoCommit() might not be propagated to the "real" JDBC connection held in JBoss? Or is the transaction context that the client cannot take part in limited to true "JTA" type transactions, UserTransaction, etc.?

Those work. That's a JDBC local transaction, not an "implicit"/contextual JTA transaction like the UserTransaction.

[weston.price]

One more 'anti-pattern', actually, it's a bug IMO. When using the Remote data source code like the following can lead to a leak pretty quickly:

try
{
 Connection conn = DataSource.getConnection()
 PreparedStatement ps = conn.prepareCall("SomeSQL");
 ps.close();

}catch(Exception e)
{

}
finally
{

 if(ps != null)
 ps.close();

 if(conn != null)
 conn.close();

}

What ends up happening in this particular instance is that the first ps.close() actually removes the Statement from the internal map on the server side. At the second close attempt a SQLException is thrown (who knows why). As a result, the connection itself would never get closed in this case. This actually crept up on the TCK for Oracle10g and was causing all sorts of issues.

Yes, I know that to be 'truly' safe both the ps.close() and the conn.close() should be contained within their own try/catch/finally block but this is never a guarantee.