[ https://jira.jboss.org/jira/browse/JBTM-510?page=com.atlassian.jira.plugi... ] Andrew Dinn closed JBTM-510. ---------------------------- Resolution: Done This has been fixed but, possibly, sub-optimally. Ideally, the subordinate transaction should be created by the Activation Coordinator service identified by the Coordinator URL specified in the web service JVM/AS. The returned context can then be associated with the parent context and the context handler can detect this and reinstate the parent when it sees another web service request. The problem is how to delete this association if the coordinator URL does not identify the (JVM/AS-)local coordinator service. If the coordinator is in another JVM then any commit or rollback operation performed by the subordinate coordinator cannot modify the association maintained in the web service JVM. The handler could register a synchronization to clean up the association when it first creates the subordinate transaction, either with the parent transaction or with the subordinate (note that the association need not survive a crash since web service requests should not occur after prepare). The current fix has the handler bypass the normal route to the Activation Coordinator and instead go direct to the local context factory i.e. it ignores any Coordinator URL setting and invokes the local coordinator back end. It registers a callback with the local subordinate coordinator implementation to be run at commit or rollback. This callback removes the parent to subordinate association. It's a little hacky but it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira