openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: TransactionSynchronizationRegistry reference cached permanently
Date Wed, 20 Aug 2008 03:46:54 GMT

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
View raw message