[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 3:00 PM: ---------------------------------------------------------------------- Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... The commented class diagram for this applying the change you recommended is here: https://drive.google.com/open?id=0B_dEiNBGUsxqY3VJZVl0d19Ub3M I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. was (Author: nuno.godinhomatos): Hi, Ok, so I have done a commit that on first testing seems to address the bug. This commit can be checked upon: https://github.com/99sono/wildfly/commit/727c652e001d172a8fe2b41cac42fec2... I have not actually tried to patch my widfly 10.1.0.Final nor have I run any of our system tests to validate that this is ok. I see if I get a window of opportunity for this tomorrow. One thing that is not clear to me. Is there any need to "unregister" from the javax.transaction.TransactionSynchronizationRegistry? Or is the specification somehow detailing that the container is responsible of cleaning up its state once the transaction reaches the end of its life? The JPA persistence layer therefore must register but not necessarily unregister? I have written no code for doing such a de-registration. Nor have I found any hint on the eclipselink code for the need of doing this. Since, in any case, the TransactionSynchronizationRegistry seems to only offer APIs to put resources and register but not for the opposite operation, I am under the impression that the logic implemented should be safe and not lead to any unexpected leaks. I await your feedback. Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)