[jBoss-Dev] FW: [jBoss-User] LOCKING-WAITING (TRANSACTION)

[marc fleury]

Title: 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(XAConnectionFactory.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(EnterpriseEntityBean.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(EntityInstanceInterceptor.java:130)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
..
.. stack trace...

  Marko.