| Anonymous | Login | Signup for a new account | 12-17-2024 08:27 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0000394 | [Resin] | minor | always | 09-22-05 00:00 | 11-30-05 14:42 | ||||
| Reporter | mate | View Status | public | ||||||
| Assigned To | |||||||||
| Priority | immediate | Resolution | fixed | ||||||
| Status | closed | Product Version | 2.1.x | ||||||
| Summary | 0000394: Connections leak when DBPool is not first JTA resource manager | ||||||||
| Description |
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. |
||||||||
| Additional Information | |||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
| There are no notes attached to this issue. |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 09-22-05 00:00 | mate | New Issue | |
| 11-30-05 00:00 | administrator | Fixed in Version | => 3.0.15 |
| 11-30-05 14:42 | ferg | Status | resolved => closed |
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed. 26 unique queries executed. |  |
