1 Reply Latest reply on Oct 31, 2006 4:26 PM by Weston M. Price

    WrapperDataSourceService

    myles_na_gopaleen Newbie

      Hi. the invoke() method of this MBean (org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService) deems it illegal access if the JDBC object associated with the invocation cannot be found in its respective local map (where it was cached when it was created). I'm doing load tests of a web app and what I'm seeing is that the MBean is allowing more that one client to obtain a remote reference to a JDBC object while it is already in use by another and before the first client has called close() (which removes the object from the service cache). For instance, two clients get a remote reference to the same Statement. ClientA closes the statement. The statement is removed from the cache. Now any method ClientB invokes via his reference is illegal. I've enhanced the MBean logging. This excerpt bears out what I've described.


      2006-10-30 09:43:11,637 DEBUG Created Statement proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=ImagearcOracleDS, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
      2006-10-30 09:43:11,637 DEBUG Created Statement proxy for invoker=jboss:service=invoker,type=jrmp, targetName=jboss.jca:service=DataSourceBinding,name=ImagearcOracleDS, cacheID=14134277 : thread=RMI TCP Connection(6)-xx.xx.x.xxxx
      2006-10-30 09:43:11,637 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.PreparedStatement.setInt(int,int) throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
      2006-10-30 09:43:11,637 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract java.sql.ResultSet java.sql.PreparedStatement.executeQuery() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
      2006-10-30 09:43:11,668 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.PreparedStatement.setInt(int,int) throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(4)-xx.xx.x.xxxx
      2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract int java.sql.Statement.getMaxRows() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(6)-xx.xx.x.xxxx
      2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract int java.sql.Statement.getQueryTimeout() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
      2006-10-30 09:43:11,684 TRACE doStatementMethod, stmt=org.jboss.resource.adapter.jdbc.WrappedPreparedStatement@d7ac05, method=public abstract void java.sql.Statement.close() throws java.sql.SQLException, cacheID=14134277 : thread=RMI TCP Connection(3)-xx.xx.x.xxxx
      2006-10-30 09:43:11,684 DEBUG Closed Statement=14134277
      2006-10-30 09:43:11,699 DEBUG SQLException : executeQuery : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(4)-xx.xx.x.xxxx
      2006-10-30 09:43:11,715 DEBUG SQLException : getMaxRows : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(1)-xx.xx.x.xxxx
      2006-10-30 09:43:11,824 DEBUG SQLException : close : Failed to find Statement : cacheID=14134277 : thread=RMI TCP Connection(1)-xx.xx.x.xxxx


      The app is deployed in JBoss 4.0.2 and uses Hibernate (the version that ships w/JBoss) for persistence. I'm looking for an explanation and would appreciate any help. Thanks.

      P.

        • 1. Re: WrapperDataSourceService
          Weston M. Price Master

          From the Wiki:


          Note: JBoss does not recommend using this feature on a production environment. It requires accessing a connection pool remotely and this is an anti-pattern as connections are not serializable. Besides, transaction propagation is not supported and it could lead to connection leaks if the remote clients are unreliable (i.e crashes, network failure). If you do need to access a datasource remotely, JBoss recommends accessing it via a remote session bean facade.


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

          There are a series of JIRA tasks designed to improve remote datasource access. These are slated for JBoss5.x. Until then the remote access in JBoss is to be considered experimental.