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 Tue, 19 Aug 2008 18:21:04 GMT
On Tue, Aug 19, 2008 at 1:05 PM, Craig L Russell <Craig.Russell@sun.com>wrote:

>
> 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.
>

But, I don't see how the app server gets reset without the OpenJPA runtime
also getting reset.  OpenJPA is not remotable, so OpenJPA exists in the same
JVM as the application server.  This is the part of the scenario that
confuses me.  I don't understand how the reference to the TSR doesn't get
reset.


Kevin


> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message