6 Replies Latest reply on Apr 18, 2007 8:56 AM by Weston M. Price

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

    Gourab Guha Newbie

      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

        • 2. Re: Problem of accessing Oracle DS in JBOSS from a stand-alo
          scott long Newbie

          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

          • 3. Re: Problem of accessing Oracle DS in JBOSS from a stand-alo
            Adrian Brock Master

             

            "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.

            • 4. Re: Problem of accessing Oracle DS in JBOSS from a stand-alo
              scott long Newbie

              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.?


              • 5. Re: Problem of accessing Oracle DS in JBOSS from a stand-alo
                Adrian Brock Master

                 

                "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.

                • 6. Re: Problem of accessing Oracle DS in JBOSS from a stand-alo
                  Weston M. Price Master

                  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.