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 16:55:19 GMT
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.

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

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