Help Desk Ticket Reference: https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000AvUyo&sfdc.override=1 project_key: JBPAPP6 A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values. More details in the referenced forum thread and the jira.
Link: Added: This issue relates to AS7-5641
SourceForge Reference: Added: https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000AvUyo&sfdc.override=1 Forum Reference: Removed: https://community.jboss.org/thread/205790 Added: https://community.jboss.org/thread/205790
Help Desk Ticket Reference: Added: https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000AvUyo&sfdc.override=1 SourceForge Reference: Removed: https://gss--c.na7.visual.force.com/apex/Case_View?id=500A000000AvUyo&sfdc.override=1 Forum Reference: Removed: https://community.jboss.org/thread/205790 Added: https://community.jboss.org/thread/205790
Hi Ravi, This got assigned to me but the AS7 issue is assigned to David, so I am assigning it to him. Thanks, Tom
Docs QE Status: Removed: NEW
From the forum thread from jhaliday: "Per the spec the timeout is NOT scoped to the transaction, it's scoped to the Thread. If you want to reset it, you explicitly call setTransactionTimeout(0). Arguably in a Thread pooled environment it's the job of the pooling logic to do that, to give the user the impression they have a new Thread even when it's actually recycled. But that's for the EJB container to address, not the transaction manager. The TM is not aware of the thread pooling and has no opportunity to do such a reset. This is not a TM bug." So.. this is not a bug. How do I reject a BZ?
This indeed is a bug. Although it is not a TM bug, it is a bug in the EJB container.
FWIW my comment #6 is nonsense. There is a fix just about ready for this issue.
Verified in EAP 6.4.0.DR11