[
http://jira.jboss.com/jira/browse/JBCACHE-1246?page=all ]
Brian Stansberry reopened JBCACHE-1246:
---------------------------------------
Assignee: Brian Stansberry (was: Manik Surtani)
The current fix assumes that the tx associated with the thread can always be safely
removed from the TransactionTable. That's not true if that tx has been in place
during previous calls w/o Option.setFailSilently(true). If such a tx is removed, when the
synchronizations kick in at commit, the TransactionEntry is gone and the commit fails.
This leads to the failure shown on
http://hudson.qa.jboss.com/hudson/view/EJB3/job/ejb3-jbpapp-4.3-testsuite....
I'm experimenting with adding a flag to TransactionEntry that gets set to true
whenever any locks, modifications, etc. are associated with the entry. The TxInterceptor
could then check that flag and not do the removal.
TransactionTable leaks memory when used with FAIL_SILENTLY option
-----------------------------------------------------------------
Key: JBCACHE-1246
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1246
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.0.0.GA, 1.4.1.SP4, 1.4.1.SP8
Environment: Windows XP, Sun HotSpot 5 Update 12, Unit
WebSphere 6.1, Windows XP
Reporter: Matt Accola
Assigned To: Brian Stansberry
Priority: Blocker
Fix For: 2.1.0.GA, 1.4.1.SP9
Attachments: Test_CacheLeak.java
When using failSilently Option one entry per cache put is leaked to the 2 HashMaps in
TransationTable class. A complete description of the problem is detailed here,
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=125724. Unit test is
attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira