You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2006/10/31 01:08:19 UTC
[jira] Resolved: (OPENEJB-300) transaction policy interceptors must
not enlist caller's connections
[ http://issues.apache.org/jira/browse/OPENEJB-300?page=all ]
David Jencks resolved OPENEJB-300.
----------------------------------
Resolution: Fixed
The original code (in 1.1.1) appears to have a bug that the callers connection context is registered during transaction completion: this means that a connection obtained during a beforeCompletion synch call will be incorrectly registered with the caller's context, not the target context.
Fixed by adding an interceptor to register a dummy empty context before the tx interceptors, and having the ConnectionTrackingInterceptor NOT replace the dummy context on exit. First part prevents callers' cx from registering in a new tx, 2nd part makes sure beforeCompletion executes in correct context.
rev 469321.
Also cleaned up the geronimo tx listener notifications to the ConnectionTrackingCoordinator in rev 469323: we only need to notice when a new tx starts.
> transaction policy interceptors must not enlist caller's connections
> --------------------------------------------------------------------
>
> Key: OPENEJB-300
> URL: http://issues.apache.org/jira/browse/OPENEJB-300
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
> Affects Versions: 2.2
> Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 2.2
>
>
> Instance interceptors are all after the tx interceptors. As a result, when a tx interceptor starts a new tx, ConnectionTrackingCoordinator.newTransaction is called and attempt to enroll any connection handles the CALLER has open in the new transaction. These handles are not going to be available to the called ejb so this is certainly wrong.
> I think we can install a blank ConnectorInstanceContext in the CTC while the tx interceptors are traversed. The alternative would be to find some way to distinguish between container and bean managed transactions inside the tx manager.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira