Bugs item #516953, was opened at 2002-02-13 13:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516953&group_id=22866
Category: None
Group: v2.4 (stable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Chris Harris (charris)
Assigned to: Nobody/Anonymous (nobody)
Summary: setRollbackOnly() in sfsb behaviour
Initial Comment:
JBoss 2.4.3, JDK1.3.1 on Win2000.
The attached file contains a simple sfsb with a single
method that calls EJBContext.setRollbackOnly(). Two
consecutive calls to this method from an ordinary java
client result in the following exception propagated
back to the client:
=========================
java.rmi.ServerException: RemoteException occurred in
server thread; nested exception is:
javax.transaction.TransactionRolledbackExceptio
n: Application Error: no concurrent calls on stateful
beans; nested exception is:
java.rmi.RemoteException: Application Error:
no concurrent calls on stateful beans
javax.transaction.TransactionRolledbackException:
Application Error: no concurrent calls on stateful
beans; nested exception is:
java.rmi.RemoteException: Application Error:
no concurrent calls on stateful beans
java.rmi.RemoteException: Application Error: no
concurrent calls on stateful beans
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(StreamRemoteCall.java:245)
at
sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invoke(Unknown Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericProxy.java:357)
at
org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionPr
oxy.invoke(StatefulSessionProxy.java:136)
at $Proxy1.error(Unknown Source)
at
com.lombardrisk.trading.test.StatefulTestBeanTest.main
(StatefulTestBeanTest.java:24)
==================================
On the server, this exception is preceded by:
===================================
[StatefulSessionEnterpriseContext] locked < 0
java.lang.Throwable
at org.jboss.ejb.EnterpriseContext.unlock
(EnterpriseContext.java:170)
at
org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto
r$InstanceSynchronization.afterCom
pletion(StatefulSessionInstanceInterceptor.java:410)
at tyrex.tm.impl.TransactionImpl.forget
(TransactionImpl.java:2009)
at tyrex.tm.impl.TransactionImpl.rollback
(TransactionImpl.java:541)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:352)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:99)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:195)
at
org.jboss.ejb.StatefulSessionContainer.invoke
(StatefulSessionContainer.java:341)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.
invoke(JRMPContainerInvoker.java:3
95)
at java.lang.reflect.Method.invoke(Native
Method)
at sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:241)
at sun.rmi.transport.Transport$1.run
(Transport.java:152)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:148)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:465)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru
n(TCPTransport.java:706)
at java.lang.Thread.run(Thread.java:484)
[StatefulSessionEnterpriseContext] locked < 0
java.lang.Throwable
at org.jboss.ejb.EnterpriseContext.unlock
(EnterpriseContext.java:170)
at
org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto
r$InstanceSynchronization.afterCom
pletion(StatefulSessionInstanceInterceptor.java:410)
at tyrex.tm.impl.TransactionImpl.forget
(TransactionImpl.java:2009)
at tyrex.tm.impl.TransactionImpl.rollback
(TransactionImpl.java:541)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:352)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:99)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:195)
at
org.jboss.ejb.StatefulSessionContainer.invoke
(StatefulSessionContainer.java:341)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.
invoke(JRMPContainerInvoker.java:3
95)
at java.lang.reflect.Method.invoke(Native
Method)
at sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:241)
at sun.rmi.transport.Transport$1.run
(Transport.java:152)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:148)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:465)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru
n(TCPTransport.java:706)
at java.lang.Thread.run(Thread.java:484)
======================================
To me, this is wrong. Calling setRollbackOnly() (and
not throwing a system exception in the remote method)
should simply roll back the transaction - the sfsb
should be available for further use. Yet it seems that
the sfsb is not being unlocked properly if no
exception is thrown. I suspect the problem may lie in
the locking code of EnterpriseContext.java but don't
have the expertise to suggest a patch.
If an application exception is thrown from the bean
method instead of just returning a value (e.g. throw a
NumberFormatException after the call to
setRollbackOnly) subsequent calls produce a
serialisation error indicating that the bean instance
has been destroyed. Again, I don't think this should
happen since this behaviour should only occur after a
system exception is thrown (ejb 2.0 spec $18.4.1, ejb
1.1 spec 12.4.1).
Behaviour if throwing a system exception is as
expected.
----------------------------------------------------------------------
>Comment By: Chris Harris (charris)
Date: 2002-05-24 16:52
Message:
Logged In: YES
user_id=8915
I'm seeing it again in 2.4.5 release, with the same test case.
We've done some investigation and the problem seems to be
that StatefulSessionContext.unlock() is being called too
many times. The last call to unlock() is in
StatefulSessionInstanceInterceptor$InstanceSynchronization.
afterCompletion() - which is called without a corresponding
call to beforeCompletion() if the transaction rolls back, as per
the EJB spec. The problem seems to be that
beforeCompletion() calls ctx.lock() and afterCompletion() calls
ctx.unlock() - the calls are expected to occur in pairs to
ensure the lock count stays correct.
Here's the killer - it only happens when I use Tyrex instead of
the standard JBoss tm. The only way I can get it to work
under Tyrex is to patch StatefulSessionInstanceInterceptor
line 444 to read
if(ctx.isLocked()) { ctx.unlock(); }
instead of
ctx.unlock();
but I'm not familiar enough with the locking code to know
whether that has other repercussions.
The standard tm doesn't work with our XA database drivers
(Oracle OR SQL Server) so is not an option right now. We
have to use Tyrex.
I haven't reopened this bug on SF - don't know whether
Tyrex/JBoss integration is 'supported enough' to make this a
JBoss bug.
----------------------------------------------------------------------
Comment By: Scott M Stark (starksm)
Date: 2002-04-10 00:42
Message:
Logged In: YES
user_id=175228
This behavior is no longer seen as of the 2.4.5RC1 release.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516953&group_id=22866
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
