You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Blevins <da...@visi.com> on 2008/08/16 01:10:53 UTC
TransactionSynchronizationRegistry reference cached permanently
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)
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Kevin Sutter <kw...@gmail.com>.
I have opened OPENJPA-696 (https://issues.apache.org/jira/browse/OPENJPA-696)
for this problem.
On Thu, Aug 21, 2008 at 10:21 AM, Kevin Sutter <kw...@gmail.com> wrote:
> David,
> Thanks for the clarifications. When we get to a more componentized
> environment, the reset of the TSR could happen independently from the rest
> of the runtime. I will open an Issue for this request. It should not be
> that difficult to modify. Thanks for the discussion.
>
> Kevin
>
>
> On Tue, Aug 19, 2008 at 10:46 PM, David Blevins <da...@visi.com>wrote:
>
>>
>> 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
>>
>>
>
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Kevin Sutter <kw...@gmail.com>.
David,
Thanks for the clarifications. When we get to a more componentized
environment, the reset of the TSR could happen independently from the rest
of the runtime. I will open an Issue for this request. It should not be
that difficult to modify. Thanks for the discussion.
Kevin
On Tue, Aug 19, 2008 at 10:46 PM, David Blevins <da...@visi.com>wrote:
>
> 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
>
>
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by David Blevins <da...@visi.com>.
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
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Kevin Sutter <kw...@gmail.com>.
On Tue, Aug 19, 2008 at 1:05 PM, Craig L Russell <Cr...@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!
>
>
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Craig L Russell <Cr...@Sun.COM>.
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
> <da...@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!
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Kevin Sutter <kw...@gmail.com>.
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 <da...@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!
>>
>>
>
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by David Jencks <da...@yahoo.com>.
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!
>
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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!
Re: TransactionSynchronizationRegistry reference cached permanently
Posted by Kevin Sutter <kw...@gmail.com>.
Hi David,
Can you expand on your scenario just a bit? If OpenJPA is using a
TransactionManager and TransactionSynchronizationRegistry, then isn't it
running in a managed container environment (ie. app server)? And, if the
app server gets rebooted, wouldn't OpenJPA get rebooted at the same time?
Or, is your scenario allowing an OpenJPA "client" to access the
Transaction-related resources in an app server process separate from the
client?
Thanks,
Kevin
On Fri, Aug 15, 2008 at 6:10 PM, David Blevins <da...@visi.com>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)
>
>