Anonymous | Login | Signup for a new account | 12-17-2024 08:43 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 | ||||
0002227 | [Resin] | major | always | 12-05-07 15:28 | 01-03-08 16:39 | ||||
Reporter | mackd2 | View Status | public | ||||||
Assigned To | ferg | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.1.4 | ||||||
Summary | 0002227: PoolItem not releasing resources after XAResource.prepare returns XA_RDONLY | ||||||||
Description |
According to my reading of the JTA specification, XAResource.prepare may return XA_RDONLY when "The transaction branch has been read only and has been committed." Furthermore, I have examined the TransactionImpl.commit() code and discovered that it takes advantage of this fact. If prepare returns XA_RDONLY, it may (depending on the other XAResources) not call XAResource.commit(). Unfortunately, the implementation of PoolItem in Resin at the moment does not respect this. It does not check for XA_RDONLY in its prepare method. The only place that resource cleanup (and release to the pool) occurs is in commit or rollback. It seems to me that prepare in PoolItem should be checking for XA_RDONLY. If it finds it, it should clean up the resource and release it to the connection pool. We are attempting to expand our production Resin environment to use distributed transactions. This bug is causing certain connections to remain "active" forever, despite the fact that the Oracle XA driver thinks they've committed. This eventually fills the connection pool with active connections that are doing nothing and prevents subsequent requests from obtaining connections. In turn, this forces us to restart Resin. |
||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
29 total queries executed. 26 unique queries executed. |