|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 :)
Excellent!
|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).
yes, if my recollection is correct there is a comment in there about " Iknow
it is spec compliant but it is silly, let's talk about this". The spec does
call for an exception. The other thing I am thinking is I remember that it
complicated somewhat the logic with passivation so that removing it totally
is probably a simple thing. your call but this year for me it is "low tech
is good tech" and when low tech is spec compliant, why fuck with the
gorilla.
marc
|
|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.
|>
|
