I inserted some code to check the status of the rollback flag. So that
portion of my entity bean looks something like this:
System.out.println("Rollback Only status was: " +
entityContext.getRollbackOnly());
entityContext.setRollbackOnly();
System.out.println("Rollback Only status is now: " +
entityContext.getRollbackOnly());
throw new StorageSynchronizationException();
This was the output:
[ETSEvent] Rollback Only status was: false
[ETSEvent] Rollback Only status is now: true
So the rollback flag appears to behave properly. At this point, the
transaction seems to have successfully rolled back... The changes to the
entity bean do not show up in the database (as expected.)
Some interesting behavior, I'm not sure if this is what is supposed to
happen: I mentioned that "setRollbackOnly" works correctly if called in a
session bean. It does seem to work correctly there, but the server still
tries to call "ejbStore" (as mentioned in the bug#420714.) Here is a
truncated trace of what's happening, with my comments added:
>>>my comment: This message displayed from the entity bean before throwing
the exception:<<<
[RMI TCP Connection(71)-161.218.184.169] INFO root - NOT calling
setRollbackOnly()
>>>my comment: This message displayed from the calling session bean, which
just caught a StorageSynchronizationException:<<<
[RMI TCP Connection(71)-161.218.184.169] INFO root - Caught an application
exception, rolling back.
>>>my comment: Log4J trace noting that server has called ejbStore:<<<
[RMI TCP Connection(71)-161.218.184.169] DEBUG
siemens.sea.gts.ets.ejb.event.ETSEventBean - 2001-06-18-4 ejbStore
>>>my comment: Server exception:<<<
[RMI TCP Connection(71)-161.218.184.169] ERROR root -
java.rmi.ServerException: Store failed; nested exception is:
[RMI TCP Connection(71)-161.218.184.169] ERROR root -
java.lang.RuntimeException: Unable to register with TransactionManager:
javax.transaction.RollbackException: Already marked for rollback
[RMI TCP Connection(71)-161.218.184.169] ERROR root -
java.lang.RuntimeException: Unable to register with TransactionManager:
javax.transaction.RollbackException: Already marked for rollback
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.opentools.minerva.jdbc.xa.XAConnectionFactory.prepareObject(XAConnection
Factory.java:279)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.opentools.minerva.pool.ObjectPool.getObject(ObjectPool.java:548)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.opentools.minerva.pool.ObjectPool.getObject(ObjectPool.java:521)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.opentools.minerva.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSourc
e.java:165)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.getConnection(JDBCCommand.java:6
79)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCCommand.java:152
)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.jaws.jdbc.JDBCStoreEntityCommand.execute(JDBCStoreEnti
tyCommand.java:97)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.storeEntity(JAWSPersistenc
eManager.java:156)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenceManage
r.java:401)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor$InstanceSynchronizati
on.beforeCompletion(EntitySynchronizationInterceptor.java:342)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1228)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.tm.TxCapsule.rollback(TxCapsule.java:410)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:88)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:307)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:
326)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:392)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
java.lang.reflect.Method.invoke(Native Method)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
sun.rmi.transport.Transport$1.run(Unknown Source)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
java.security.AccessController.doPrivileged(Native Method)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
sun.rmi.transport.Transport.serviceCall(Unknown Source)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
[RMI TCP Connection(71)-161.218.184.169] ERROR root - at
java.lang.Thread.run(Unknown Source)
This does not cause any problems in my case.
I understand that the LOCKING-WAITING message is normal, after reading
through the mailing list archives. However, in a situation such as this
where the transaction is not released, it slows the server to a crawl while
thousands of LOCKING-WAITING messages go into the logfile (which grows and
grows, not unexpected behavior so I'm not complaining.) The transaction
eventually times out, but the entity bean remains locked until I restart the
application server.
Mike
----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 28, 2001 11:46 AM
Subject: RE: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> hmmmm
>
> can't get get from the transaction what the status of the rollback only
flag
> is?
>
> quick question do new resources enroll in it none the less?
>
> the LW is normal but what would you expect (you want and /or spec)
>
> marcf
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Michael Jara
> |Sent: Thursday, June 28, 2001 1:05 PM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> |
> |
> |Yes, Sybase ASE is case sensitive as to table and column names. (SQL
> |keywords may be any case.) I beleive this is not unique to Sybase, but
is
> |also the case in some other database servers such as Oracle. JAWS in
JBoss
> |2.2.2 works properly, but Beta 2.4 does not... I get SQL errors, and the
> |trace shows all of the finder text from my jaws.xml file to be
lower-cased.
> |
> |As to the "setRollbackOnly" problem, I'm guessing that the only way
around
> |is simply to avoid using "setRollbackOnly". This may present a
maintenance
> |problem, but with some careful coding, it will be the quickest solution
to
> |my problem. (I have recently ported our app from Orion to JBoss because
> |Orion had problems with EJB security... I guess no app server is
perfect.)
> |
> |Has nobody else noticed this problem?
> |
> |Mike
> |
> |----- Original Message -----
> |From: "danch" <[EMAIL PROTECTED]>
> |To: <[EMAIL PROTECTED]>
> |Sent: Wednesday, June 27, 2001 11:02 PM
> |Subject: Re: [JBoss-user] LOCKING-WAITING after setRollbackOnly()
> |
> |
> |> Michael Jara wrote:
> |>
> |> > I've run into a problem previously mentioned in the archives here:
> |> >
>
|http://www.mail-archive.com/[email protected]/msg03141.html
> |> >
> |> >
> |> >
> |> > Does anyone have a good workaround for this (aside from "don't use
> |> > setRollbackOnly", or "hack TxCapsule and build it yourself"?) This
> |> > seems like a pretty major issue, I'm a little surprsed to see
> |it present
> |> > in JBoss at this stage (release version 2.2.2.)
> |> >
> |> >
> |> >
> |> > After a quick scan of the latest source changes, it didn't
> |look to me as
> |> > if this had been touched (although I am admittedly clueless as to how
> |> > most of this stuff is implemented.) There is a bug logged, #420714,
> |> > which seems to refer to this problem. Unfortunately, the
> |description is
> |> > pretty sparse, so I'm not sure if it is the exact same problem. At
any
> |> > rate, the bug is unassigned and is marked medium priority. Do any of
> |> > you JBoss gurus out there have this on your bug-fix to-do list? (I'd
> |> > take a crack at it, but being new to JBoss, I'm not really
qualified.)
> |> >
> |> >
> |> >
> |> > BTW, I tried deploying my jar in the beta 2.4, and my app wouldn't
even
> |> > run. It appears that JAWS is broken, it lower-cased all of
> |the SQL text
> |> > in my custom finders. While this might work for databases such as
> |> > Hypersonic, Sybase ASE (what I'm using) is case-sensitive.
> |>
> |> Case sensitive with regard to table and column names?
> |>
> |>
> |> -danch
> |>
> |>
> |> _______________________________________________
> |> JBoss-user mailing list
> |> [EMAIL PROTECTED]
> |> http://lists.sourceforge.net/lists/listinfo/jboss-user
> |>
> |
> |
> |_______________________________________________
> |JBoss-user mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
