openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: TransactionSynchronizationRegistry reference cached permanently
Date Thu, 21 Aug 2008 15:26:28 GMT
I have opened OPENJPA-696 (https://issues.apache.org/jira/browse/OPENJPA-696)
for this problem.

On Thu, Aug 21, 2008 at 10:21 AM, Kevin Sutter <kwsutter@gmail.com> 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 <david.blevins@visi.com>wrote:
>
>>
>> On Aug 19, 2008, at 11:21 AM, Kevin Sutter wrote:
>>
>>  On Tue, Aug 19, 2008 at 1:05 PM, Craig L Russell <Craig.Russell@sun.com
>>> >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
>>
>>
>

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