openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: TransactionSynchronizationRegistry reference cached permanently
Date Thu, 21 Aug 2008 15:26:28 GMT
I have opened OPENJPA-696 (
for this problem.

On Thu, Aug 21, 2008 at 10:21 AM, Kevin Sutter <> wrote:

> David,
> Thanks for the clarifications.  When we get to a more componentized
> environment, the reset of the TSR could happen independently from the rest
> of the runtime.  I will open an Issue for this request.  It should not be
> that difficult to modify.  Thanks for the discussion.
> Kevin
> On Tue, Aug 19, 2008 at 10:46 PM, David Blevins <>wrote:
>> On Aug 19, 2008, at 11:21 AM, Kevin Sutter wrote:
>>  On Tue, Aug 19, 2008 at 1:05 PM, Craig L Russell <
>>> >wrote:
>>>> At the risk of overreaching, the scenario described by David is that the
>>>> transaction management component (TMC hereinafter) of the application
>>>> server
>>>> is being reset, invalidating the object (hereinafter TSR) that was bound
>>>> to
>>>> java:comp/TransactionSynchronizationRegistry.
>>>> After the TMC is reset, the new TSR instance is bound to the same JNDI
>>>> address. Since OpenJPA has a reference to the old TSR instance, it
>>>> doesn't
>>>> work after the reset.
>> That captures it pretty well.
>>  But, I don't see how the app server gets reset without the OpenJPA
>>> runtime
>>> also getting reset.
>> Right, if we rebooted the VM we wouldn't have any issues.  This is more
>> along the lines of taking the concept of restarting an application in a live
>> server and expanding it to support restarting some or all of the environment
>> that supports the application, even down to the transaction
>> manager/transaction synchronization registry.
>> Obviously this isn't something you'd do in a full multi-app EE scenario.
>>  Where we really need this is in the Java SE scenario where the user is
>> booting an embeddable EJB container in their VM, doing some work (usually
>> unit testing), and possibly shutting it down then repeating this in another
>> test case in the same VM  with possibly different environment settings.  We
>> currently support the scenario where you boot the EJB container in your vm
>> and use it for all your tests and test cases; if you want a different setup
>> you need to run your test in a new vm.  But we're adding support for various
>> kinds of "tearDown" logic that ranges from logout to undeploying the app to
>> fully cleaning up the EJB container environment.
>> Not sure how this would fit into the OpenJPA code, but if the lookup of
>> the "java:comp/TransactionSynchronizationRegistry" could be done once per
>> EntityManagerFactory the same way TransactionManager is currently, that'd be
>> ideal.
>> -David

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message