Mantis - Resin
Viewing Issue Advanced Details
394 minor always 09-22-05 00:00 11-30-05 14:42
mate  
 
immediate  
closed 2.1.x  
2.1.x fixed  
none    
none 3.0.15  
0000394: Connections leak when DBPool is not first JTA resource manager
RSN-440
There is a bug in the handling of JTA transactions with the database pool. It turns out that if you enlist non-database pool resources *before* getting a connection from the pool, the connections will not be reused within the transaction, but instead the pool will start leaking (even if the connections are properly closed in the application). If there are more DB pool lookups than the maximum number of connections in the pool, the application will halt.

While tracking down this bug, I realized that the first Xid created is the one associated with the threads transaction. When other resources (from other resource manager) are enlisted, the are assigned a separate Xid with a unique branch (see TransactionImpl line 315). Then, when the DB pool tries to retrieve a connection that has already been used in the transaction, but returned to the pool, it uses the simple object reference comparison; see PoolItem line 274:

      else if (_xid != xid) // different transaction
        return false;

The global part is the same, but the local part/branch differs, and it is two different object, so the pool won't find any match and will return a new connection. This new connection will also get an Xid different from the one associated with the thread. And so on and so forth...
Attached servlet will demonstrate the problem.

My personal opinion is that this bug is critical enough by itself to motivate a 2.1.17 release.

There are no notes attached to this issue.