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:21:03 GMT
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