glassfish
  1. glassfish
  2. GLASSFISH-16841

unshareable connections enlisted in one transaction can be acquired by another bean acting in a separate transaction

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: jca
    • Labels:
      None
    • Environment:

      all platforms

      Description

      I wrote a XA transactinal connection factory which is injected into a stateless session bean. This factory is Unshareable. When this bean is used for the first time everything is OK, i.e. a connection is retrieved from this factory and it is enlisted in the transaction manager. At the end of bean's transactional method this connection is put back to the pool and delisted from the transaction manager.

      But when this bean is used for the second time, there is an associated session context with a list of resources. In this list, there exists a resource handle with the connection which was used in the previous invocation of this bean. Before the body of the invoked method is executed, this resource handle is enlisted in a new transaction, although this connection is not yet acquired from the factory. It will be done in this body (I think that it is some optimization, which assumes that the same connection will be obtained from the pool once more time).

      But it is a trap! Another concurrent instance of bean can get this enlisted connection before the above mentioned instance of bean do it. This connection (resource handle with this connection) has the "enlisted" flag set to true, and it is not (and of course shouldn't be) enlisted once more time. So this connection takes a part in a separate transaction than it is used.

      In the method getResourceFromPool of the class com.sun.enterprise.resource.pool.ConnectionPool, there is even the following comment:

      // the order of serving a resource request
      // 1. free and enlisted in the same transaction
      // 2. free and unenlisted
      // Do NOT give out a connection that is
      // free and enlisted in a different transaction
      

      But there is no verification of this flag anywhere. Even in the method ds.getResource(), where I think it should be (ds is an instance of the class RWLockDataStructure).

      This "enlisted" flag should be checked in the method getResourceFromPool (especially that this method is invoked from the method getUnenlistedResource), or no caching of the previous resource handles should be done in the session context of the bean. Why such caching is done - getting a connection from the pool is done independently of this caching?

        Activity

        Hide
        Jagadish added a comment -

        When a connection is not explicitly closed by the application (eg: bean method), it will remain associated with the bean (bean is caching the connection).
        Whenever the bean is used again, any resources (connections) still associated with the bean will also take part in the transaction.

        I do not expect the use-case where the connection is returned to the pool, but still associated with the bean.

        Following test-case setup works fine :
        [I see that connection is registered and unregistered with the component appropriately]

        jdbc-connection-pool monitoring set to HIGH
        [ asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH' ]

        Stateless session bean
        Resource Sharing is set to Unshareable
        Acquires an XA resource (jdbc connection) in the transactional context
        does DB work
        releases the resource

        [number of free connections remain the same (8) ]

        Run the same test-case

        [number of free connections remain the same (8) ]

        Could you provide a test-case that exhibits the reported behavior ?

        Show
        Jagadish added a comment - When a connection is not explicitly closed by the application (eg: bean method), it will remain associated with the bean (bean is caching the connection). Whenever the bean is used again, any resources (connections) still associated with the bean will also take part in the transaction. I do not expect the use-case where the connection is returned to the pool, but still associated with the bean. Following test-case setup works fine : [I see that connection is registered and unregistered with the component appropriately] jdbc-connection-pool monitoring set to HIGH [ asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH' ] Stateless session bean Resource Sharing is set to Unshareable Acquires an XA resource (jdbc connection) in the transactional context does DB work releases the resource [number of free connections remain the same (8) ] Run the same test-case [number of free connections remain the same (8) ] Could you provide a test-case that exhibits the reported behavior ?
        Hide
        michal_kozak added a comment -

        The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection.

        I realized that this use-case is not proper so I changed now my resource adapter and I supplemented an interface of the connection with the close method which does it before the end of transaction.

        Now it's OK. I'm sorry for the confusion

        Show
        michal_kozak added a comment - The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection. I realized that this use-case is not proper so I changed now my resource adapter and I supplemented an interface of the connection with the close method which does it before the end of transaction. Now it's OK. I'm sorry for the confusion
        Hide
        Jagadish added a comment -

        "The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection."

        I have not fully understood the above explanation.

        Marking as "not an issue" as you have resolved the issue in your implementation.

        Show
        Jagadish added a comment - "The connection is returned to the pool and still associated with the bean, when it is closed in the commit or rollback method of the XAResource interface for this connection." I have not fully understood the above explanation. Marking as "not an issue" as you have resolved the issue in your implementation.

          People

          • Assignee:
            Jagadish
            Reporter:
            michal_kozak
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: