I believe this should be fixed. Ole did some exception handling clean up
in the transaction interceptors.
Alhtough the problem I noticed was with runtime exceptions from ejbStore
and possibly other callbacks; business methods should have been working (I
think)
danch
On Fri, 9 Feb 2001, marc fleury wrote:
> RE: [jBoss-User] LOCKING-WAITING (TRANSACTION)Hey was this fixed in the new
> version? I know we worked with the exception problems...
>
>
> mac
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marko �trukelj
> Sent: Friday, February 09, 2001 3:12 AM
> To: 'jBoss'
> Subject: RE: [jBoss-User] LOCKING-WAITING (TRANSACTION)
>
>
> I've been having a lot of problems with LOCKING-WAITING too. Jboss would
> just freeze up at a certain point. So I've done some detective work myself
> and solved my problem.
>
> So here are my findings:
>
>
>
> 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.
>
> 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...
>
>
>
> java.rmi.ServerException: Store failed; nested exception is:
> java.lang.RuntimeException: Unable to register with TransactionManager:
> javax.transaction.RollbackException: Already marked for rollback
>
> 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...
>
> 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...
>
>
>
>
> 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.
>
> Otherwise it is normal that LOCKING-WAITING appears when multiple clients
> try accessing the entity bean with particular primary key concurrently. It
> just means that a client is waiting for some other client to complete a
> method call - waiting for his turn. And if it waits for too long it timesout
> and you see a nasty stack trace:
>
> Transaction XidImpl [ID=257, Global=NASSER/96, Branch=] timed out.
> status=STATUS_ACTIVE
> TRANSACTION ROLLBACK EXCEPTION:Transaction marked for rollback, possibly a
> timeout; nested exception is:
> java.lang.RuntimeException: Transaction marked for rollback,
> possibly a timeout
> java.lang.RuntimeException: Transaction marked for rollback, possibly a
> timeout
> at
> org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterce
> ptor.java:130)
> at
> org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
> ..
> .. stack trace...
>
>
>
>
>
>
>
> Marko.
>
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
