Hi,
Dan Christopherson wrote:
>
> I believe this should be fixed. Ole did some exception handling clean up
> in the transaction interceptors.
The exception cleanup I did in the tx
interceptors was only to handle possible
races with transaction timeout that
would result in IllegalStateException
being thrown from the JTA implementation
and propagated out of these interceptors.
But about a month ago I started a thread
here with subject: "InstanceInterceptor
synchronization waiting.", where this was
discussed.
I think Simon is working on this, or about
to start working on it.
> On Fri, 9 Feb 2001, marc fleury wrote:
> > On Fri, 9 Feb 2001, Marko ©trukelj wrote:
> > Looks like there is a tiny bug in JBoss 2.0 final (I have not tested it
> > with the latest cvs snapshot).
> >
> > If a RuntimeException is thrown (i.e. NullPointerException) inside a
> > business method of a CMP Entity Bean then jboss will fail to properly return
> > a connection to the connection pool. I gather that Jboss automaticaly takes
> > a connection from connection pool - to store bean's state to the database
> > after the business method finishes - the connection is taken from the pool
> > before the business method starts executing and is normally returned to the
> > pool after ejbStore() completes. But it is not in the case of uncaught
> > RuntimeException (it makes no difference if you declare Exception in the
> > throws clause).
> >
> > That means if you have 2 connections in the pool, then you will be out of
> > them after 2 RuntimeExceptions. All the clients will just hang from that
> > point on with LOCKING-WAITING queue building up.
This is bad, if not already fixed.
The container should keep track of
what open resource connections the
bean instance has, and cloose all of
these when the instance is discarded.
I would guess that the JCA folks also
would like a hook into the container
so they can notify the container about
resource open/close events.
And this may also be needed so that
the container can enlist the resources
with the right transaction when it
changes. For example, consider an XA
resource held open while a BMT bean
starts a transaction, commits it, and
starts another one.
> > When a runtime exception occurs you see a pattern of exception messages.
> > You first get 2 stacktraces for exceptions that are a consequence and one
> > stacktrace for the actual exception that caused it all.
> >
> >
> >
> > I see it like this most of the time. (order may change sometimes, maybe
> > only because multiple threads write to the same out):
> >
> > javax.transaction.RollbackException: Already marked for rollback
> > at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:543)
> > ..
> > .. stackTrace...
This is what must be thrown according
to the JTA specificiation if the
transaction was marked for rollback
only, and an attempt to enlist a new
resource was done.
Minerva seems to catch and log this,
and throw a RuntimeException back at
the caller.
> > java.rmi.ServerException: Store failed; nested exception is:
> > java.lang.RuntimeException: Unable to register with TransactionManager:
> > javax.transaction.RollbackException: Already marked for rollback
The RuntimeException from above.
> > java.lang.RuntimeException: Unable to register with TransactionManager:
> > javax.transaction.RollbackException: Already marked for rollback
> >
> > at
> > org.jboss.minerva.factories.XAConnectionFactory.prepareObject(XAConnectionFa
> > ctory.java:262)
> > ..
> > .. stack trace...
Same RuntimeException again. Here we
have the line where Minerva threw the
exception.
> > java.lang.NullPointerException: I'm the one who caused it all - expect to
> > see some LOCKING-WAITING soon :)
> > at
> > org.jboss.zol.testbean.bean.EnterpriseEntityBean.getOtherField(EnterpriseEnt
> > ityBean.java:133)
> > at java.lang.reflect.Method.invoke(Native Method)
> > ..
> > .. stack trace...
Seems to be the bean printing this.
Cannot find a source that matches the
above line, but if the bean propagates
the NPE or RE exceptions, the instance
should be discarded, and no
LOCKING-WAITING messages should happen.
> > So when you see LOCKING-WAITING building up and if it is caused by
> > uncaught RuntimeException you should see a stacktrace of this exception in
> > the server.log file and on the console. Just fix it and you're back in the
> > game.
Maybe there is a bug in 2.0-FINAL, so
that this would not discard the
instance.
> > Otherwise it is normal that LOCKING-WAITING appears when multiple clients
> > try accessing the entity bean with particular primary key concurrently.
Rare, but normal. Not a bug, but a
warning. IMHO this can be very useful
when trying to track down a deadlock.
But to avoid scaring users, it might be
an idea to make the message reflect
that it is completely normal.
Best Regards,
Ole Husgaard.
