Re: TransactionSynchronizationRegistry reference cached permanently

[Craig L Russell]

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.


at the EMF level.  Educated guess.

Now that the TSR is available and has a defined jndi location

should bounce OpenJPA.

Unless I am missing something from your scenario that would make the
java:comp/TransactionSynchronizationRegistry accessible outside of the

compliant.

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 (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 container's managed environment... But, I don't think that would be spec

Craig

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.

Kevin

On Mon, Aug 18, 2008 at 6:08 PM, David Jencks <[EMAIL PROTECTED]>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?


the real implementation?


could delegate to the new implementation object.


proposing is the receiver of the change notification.

Specifically, since TSR implementation is registered with JNDI, could you refactor it into a permanent singleton registered in JNDI that delegates to 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 Seems like the only difference between what you're proposing and what I'm

that having different lifecycles for these references very apt to be


thanks
david jencks

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 implemented by the same object is pretty much an accident waiting to happen.

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

the app server OpenJPA will not get the new



Is it possible we can get this fixed for the next release?

-David

(pulled these stack traces of the code referencing the old


at

at

at

at

at

at

at


     --
at

at

at

at

at


     --
at

at

at

at

at


     --
at

at

at

at

at

at

at


     --
at

at

at

at

at

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 TransactionSynchronizationRegistry and of course ceases to work properly. TransactionSynchronizationRegistry, may or may not be useful to you) org.apache.openjpa.ee.RegistryManagedRuntime $ TransactionManagerRegistryFacade .getStatus(RegistryManagedRuntime.java:130) org .apache .openjpa .kernel .AbstractBrokerFactory .syncWithManagedTransaction(AbstractBrokerFactory.java:723) at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java: 320) org .apache .openjpa .kernel .AbstractBrokerFactory .initializeBroker(AbstractBrokerFactory.java:216) org .apache .openjpa .kernel .AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:190) org .apache .openjpa .kernel .DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java: 142) org .apache .openjpa .persistence .EntityManagerFactoryImpl .createEntityManager(EntityManagerFactoryImpl.java:192) org .apache .openjpa .persistence .EntityManagerFactoryImpl .createEntityManager(EntityManagerFactoryImpl.java:56) org.apache.openjpa.ee.RegistryManagedRuntime $ TransactionManagerRegistryFacade .getStatus(RegistryManagedRuntime.java:130) org .apache .openjpa .kernel .AbstractBrokerFactory .syncWithManagedTransaction(AbstractBrokerFactory.java:723) org .apache .openjpa .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391) org .apache .openjpa .kernel .DelegatingBroker .syncWithManagedTransaction(DelegatingBroker.java:893) org .apache .openjpa .persistence .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501) org.apache.openjpa.ee.RegistryManagedRuntime $ TransactionManagerRegistryFacade .registerSynchronization(RegistryManagedRuntime.java:118) org .apache .openjpa .kernel .AbstractBrokerFactory .syncWithManagedTransaction(AbstractBrokerFactory.java:735) org .apache .openjpa .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391) org .apache .openjpa .kernel .DelegatingBroker .syncWithManagedTransaction(DelegatingBroker.java:893) org .apache .openjpa .persistence .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501) org.apache.openjpa.ee.RegistryManagedRuntime $ TransactionManagerRegistryFacade .getTransactionKey(RegistryManagedRuntime.java:134) org .apache .openjpa .ee .RegistryManagedRuntime .getTransactionKey(RegistryManagedRuntime.java:88) org .apache .openjpa .ee .AutomaticManagedRuntime .getTransactionKey(AutomaticManagedRuntime.java:255) org .apache .openjpa .kernel .AbstractBrokerFactory .syncWithManagedTransaction(AbstractBrokerFactory.java:740) org .apache .openjpa .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391) org .apache .openjpa .kernel .DelegatingBroker .syncWithManagedTransaction(DelegatingBroker.java:893) org .apache .openjpa .persistence .EntityManagerImpl.joinTransaction(EntityManagerImpl.java:501) org.apache.openjpa.ee.RegistryManagedRuntime $ TransactionManagerRegistryFacade .registerSynchronization(RegistryManagedRuntime.java:118) org .apache .openjpa .kernel .AbstractBrokerFactory .syncWithManagedTransaction(AbstractBrokerFactory.java:746) org .apache .openjpa .kernel.BrokerImpl.syncWithManagedTransaction(BrokerImpl.java:1391) org .apache .openjpa .kernel .DelegatingBroker .syncWithManagedTransaction(DelegatingBroker.java:893) 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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature