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(TransactionImpl.java:585) > at > org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:475) > at > org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:258) > at > org.apache.openejb.core.transaction.JtaTransactionPolicy.rollbackTransaction(JtaTransactionPolicy.java:333) > at > org.apache.openejb.core.transaction.JtaTransactionPolicy.completeTransaction(JtaTransactionPolicy.java:283) > at > org.apache.openejb.core.transaction.TxRequired.commit(TxRequired.java:75) > at > org.apache.openejb.core.transaction.EjbTransactionUtil.afterInvoke(EjbTransactionUtil.java:74) > at > org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:241) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:174) > at > org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:136) 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 java.io.Flushable, 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. -David
