openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: TransactionSynchronizationRegistry reference cached permanently
Date Tue, 19 Aug 2008 18:05:26 GMT

On Aug 19, 2008, at 9:55 AM, Kevin Sutter wrote:

> Okay, I'm starting to understand David Blevins' initial post, but  
> I'm still
> not convinced that it's a valid concern.
>
> Prior to the TSR (TransactionSynchronizationRegistry), OpenJPA would  
> access
> the TransactionManager in a myriad number of means.  Some of which  
> were not
> looked on favorably by some of the Application Server vendors (ie.  
> WebSphere
> and their TransactionManager).  Thus, we jumped through some hoops  
> to follow
> the documented practices.  Due to these various (and inconsistent)  
> methods
> of obtaining the TransactionManager, that's probably why the TM was  
> cached
> at the EMF level.  Educated guess.
>
> Now that the TSR is available and has a defined jndi location
> (java:comp/TransactionSynchronizationRegistry), we can be more  
> consistent
> with our processing.  Since the java:comp/ 
> TransactionSynchronizationRegistry
> object is only available for Java EE managed components, caching  
> this once
> per JVM should be just fine.  In this case, the OpenJPA runtime  
> would only
> be resident in the same JVM as the app server, so bouncing the app  
> server
> should bounce OpenJPA.
>
> Unless I am missing something from your scenario that would make the
> java:comp/TransactionSynchronizationRegistry accessible outside of the
> container's managed environment...  But, I don't think that would be  
> spec
> compliant.

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.

My pay grade isn't high enough for me to work through all the  
dependencies and synchronization conditions. While the TMC is being  
reset, nothing works, so the server needs to slow or stop the  
applications that are dependent on TMC. After the reset, the new TSR  
is active.

I don't understand with all this going on, why there would be an issue  
with a delegation model in which there is one TSR that delegates to  
the now-current implementation object.

Craig
>
>
> Kevin
>
> On Mon, Aug 18, 2008 at 6:08 PM, David Jencks  
> <david_jencks@yahoo.com>wrote:
>
>>
>> On Aug 18, 2008, at 8:44 AM, Craig L Russell wrote:
>>
>> Hi David,
>>>
>>> Is it possible to fix this on the TSR implementation side?
>>>
>>> Specifically, since TSR implementation is registered with JNDI,  
>>> could you
>>> refactor it into a permanent singleton registered in JNDI that  
>>> delegates to
>>> the real implementation?
>>>
>>> And the server code notify it the JNDI instance when there is a  
>>> server
>>> state change that would invalidate the implementation. Then the  
>>> JNDI object
>>> could delegate to the new implementation object.
>>>
>>> Seems like the only difference between what you're proposing and  
>>> what I'm
>>> proposing is the receiver of the change notification.
>>>
>>
>> I don't know what the context is in openejb where this showed up,  
>> but it
>> seems to me that at a possibly more philosophical level david's  
>> point was
>> that having different lifecycles for these references very apt to be
>> implemented by the same object is pretty much an accident waiting  
>> to happen.
>>
>> thanks
>> david jencks
>>
>>
>>
>>>
>>> Craig
>>>
>>> On Aug 15, 2008, at 4:10 PM, David Blevins wrote:
>>>
>>> Seems there are some slight differences in the way OpenJPA tracks  
>>> the
>>>> TransactionManager reference versus the  
>>>> TransactionSynchronizationRegistry.
>>>> The TransactionManager appears to be fetched once per  
>>>> EntityManagerFactory,
>>>> so if the underlying app server does any sort of rebooting the new
>>>> TransactionManager instance is picked up just fine as OpenJPA  
>>>> continues to
>>>> get it from the app server.  This is good.  However when it comes  
>>>> to the
>>>> TransactionSynchronizationRegistry, it seems OpenJPA grabs it  
>>>> once for the
>>>> life of the VM and never lets it go.  So if any sort of rebooting  
>>>> happens in
>>>> the app server OpenJPA will not get the new
>>>> TransactionSynchronizationRegistry and of course ceases to work  
>>>> properly.
>>>>
>>>>
>>>> Is it possible we can get this fixed for the next release?
>>>>
>>>> -David
>>>>
>>>> (pulled these stack traces of the code referencing the old
>>>> TransactionSynchronizationRegistry, may or may not be useful to  
>>>> you)
>>>>
>>>> at
>>>> org.apache.openjpa.ee.RegistryManagedRuntime 
>>>> $ 
>>>> TransactionManagerRegistryFacade 
>>>> .getStatus(RegistryManagedRuntime.java:130)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .syncWithManagedTransaction(AbstractBrokerFactory.java:723)
>>>> at  
>>>> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java: 
>>>> 320)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .initializeBroker(AbstractBrokerFactory.java:216)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:190)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java: 
>>>> 142)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerFactoryImpl 
>>>> .createEntityManager(EntityManagerFactoryImpl.java:192)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerFactoryImpl 
>>>> .createEntityManager(EntityManagerFactoryImpl.java:56)
>>>>
>>>>      --
>>>> at
>>>> org.apache.openjpa.ee.RegistryManagedRuntime 
>>>> $ 
>>>> TransactionManagerRegistryFacade 
>>>> .getStatus(RegistryManagedRuntime.java:130)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .syncWithManagedTransaction(AbstractBrokerFactory.java:723)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .DelegatingBroker 
>>>> .syncWithManagedTransaction(DelegatingBroker.java:893)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501)
>>>>
>>>>      --
>>>> at
>>>> org.apache.openjpa.ee.RegistryManagedRuntime 
>>>> $ 
>>>> TransactionManagerRegistryFacade 
>>>> .registerSynchronization(RegistryManagedRuntime.java:118)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .syncWithManagedTransaction(AbstractBrokerFactory.java:735)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .DelegatingBroker 
>>>> .syncWithManagedTransaction(DelegatingBroker.java:893)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501)
>>>>
>>>>      --
>>>> at
>>>> org.apache.openjpa.ee.RegistryManagedRuntime 
>>>> $ 
>>>> TransactionManagerRegistryFacade 
>>>> .getTransactionKey(RegistryManagedRuntime.java:134)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .ee 
>>>> .RegistryManagedRuntime 
>>>> .getTransactionKey(RegistryManagedRuntime.java:88)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .ee 
>>>> .AutomaticManagedRuntime 
>>>> .getTransactionKey(AutomaticManagedRuntime.java:255)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .syncWithManagedTransaction(AbstractBrokerFactory.java:740)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .DelegatingBroker 
>>>> .syncWithManagedTransaction(DelegatingBroker.java:893)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501)
>>>>
>>>>      --
>>>> at
>>>> org.apache.openjpa.ee.RegistryManagedRuntime 
>>>> $ 
>>>> TransactionManagerRegistryFacade 
>>>> .registerSynchronization(RegistryManagedRuntime.java:118)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .AbstractBrokerFactory 
>>>> .syncWithManagedTransaction(AbstractBrokerFactory.java:746)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .kernel 
>>>> .DelegatingBroker 
>>>> .syncWithManagedTransaction(DelegatingBroker.java:893)
>>>> at
>>>> org 
>>>> .apache 
>>>> .openjpa 
>>>> .persistence 
>>>> .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501)
>>>>
>>>>
>>> Craig L Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message