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
