Hi,
FYI I'm working on this, and fixed but not commited yet, some of this "bad"
exception handling (found by Marko Strukelj, Arnaud Tavard and some other by
me). Give some more time to test all the stuff, pretty complicated to test
all the cases :)
BTW, anyone interested in having "concurrent" stateful calls as an option ?
(Instaead of always throwing RemoteException in case of concurrent access to
the same stateful bean. This will require a little refactoring, but it's a
simple job).
Simon
> -----Original Message-----
> From: Ole Husgaard [mailto:[EMAIL PROTECTED]]
> Sent: sabato 10 febbraio 2001 19:41
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] FW: [jBoss-User] LOCKING-WAITING
> (TRANSACTION)
>
>
> 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.
>
