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 <[EMAIL PROTECTED]> 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 <[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 >> >> >
