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 <[EMAIL PROTECTED]>wrote: > > On Aug 19, 2008, at 11:21 AM, Kevin Sutter wrote: > > On Tue, Aug 19, 2008 at 1:05 PM, Craig L Russell <[EMAIL PROTECTED] >> >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 > >
