tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: database restart during runtime?
Date Thu, 24 Feb 2011 16:15:35 GMT

On Feb 24, 2011, at 6:22 AM, joe wrote:

> Hi,
> Should it be possible to restart a database used by the OpenEJB container without restarting
the OpenEJB container itself?

We don't support that now, but I'm trying to think what it would take to pull it off.  Seems
if you were really clever with the db pooling code, you could potentially pull something like
that off.  Like any graceful restart you'd want to hold threads asking for new connections,
wait for any connections in use to return to the pool, and then you could flip that db over
and no one would notice -- sans the wait itself.

> When i restart the database, a test Java standalone client app (after restarting the
client) is not always able to lookup a remote EJB interface, sometimes (nearly 50%) an exception
is thrown, see below.
> But looking up remote EJB interfaces after this exception has occured seems to work always.
> javax.transaction.SystemException at org.apache.geronimo.transaction.manager.TransactionImpl.rollbackResources(
> 	at org.apache.geronimo.transaction.manager.TransactionImpl.rollback(
> 	at org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(
> 	at org.apache.openejb.core.transaction.JtaTransactionPolicy.rollbackTransaction(
> 	at org.apache.openejb.core.transaction.JtaTransactionPolicy.completeTransaction(
> 	at org.apache.openejb.core.transaction.TxRequired.commit(
> 	at org.apache.openejb.core.transaction.EjbTransactionUtil.afterInvoke(
> 	at org.apache.openejb.core.stateless.StatelessContainer._invoke(
> 	at org.apache.openejb.core.stateless.StatelessContainer.invoke(
> 	at org.apache.openejb.core.stateless.StatelessContainer.invoke(

The 50% makes sense.  If ever stateless instance in the containers instance pool had a stale
connection, each one would eventually throw that exception and be discarded by the container.
 The effect is that your stateless instance pool would eventually contain new stateless bean
instances and each would have a new connection (assuming they are coded with an @Resource
DataSource reference as I suspect).

If in one of the Stateless bean instance you cast the SessionContext object to,
then call flush() on it, the stateless pool will be gracefully cleaned out and restored to
a startup state. (new feature as of 3.1.3 and later)   It is thread safe as well and a heavily
tested feature.


View raw message