-
30. Re: No active JTA Tx?? Spring + JTA Tx rollback on JBossTS
D'oh. Already had my controller wired to enlist a DummyXAParticipant ... just wrapped with a isDebugEnabled() ... and it wasn't.
Retrying now ... thanks for setting me straight (again). -
31. Re: No active JTA Tx?? Spring + JTA Tx rollback on JBossTS
"jhalliday" wrote:
Last time I checked you could not write triggers on SELECTs, with the exception of some dbs that have query audit logging frameworks, which you don't want to be transactional anyhow. Even assuming you could, I'd presume the db would be smart enough to know it had modified some data within the tx and to return the right thing. Basically the XAResource implementation is part of the db driver and can be trusted to have the smarts to know what it's talking about. For example, if you issue an INSERT that fails for e.g. constraint violation, it may still consider the tx to be readonly. It will go by the internal state in the db engine. Looking at the SQL used is just a simple rule of thumb to help guess how it will behave.
Very good to know. My insulated app-centric view of the world imagined that setting @Transactional(readOnly = true) on my method was the only way that it would be read-only. Never imagined that the XAResource from the Oracle driver would be determining that as well.
Thanks!! -
32. Re: No active JTA Tx?? Spring + JTA Tx rollback on JBossTS
Well in a way the annotation will work - if you only ever access the db via code that is aware of that annotation and takes care to issue sql that the db will consider read only. But as far as the transaction manager is concerned, the annotation is irrelevant, it's going to trust the XAResources instead.
If you have the bad luck to wind up with a db driver (or db server) that does not implement the readonly optimization then the annotation won't do you much good as far as the transaction is concerned. It may catch cases where your application code contains writes and throw an exception rather than passing them along to the db though I guess. -
33. Re: No active JTA Tx?? Spring + JTA Tx rollback on JBossTS
Hallelujah.
Looks like the commit returned the connection to the pool.2008-07-30 11:11:43,062 TRACE [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Returning connection to pool org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@8ae1fb[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@1fa3fa9 handles=0 lastUse=1217434303062 permit=false trackByTx=false mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$PoolBySubject@e8a591 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@698f02 xaResource=org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper@2be20e txSync=null] [InUse/Available/Max]: [0/10/5]
So, that's not good, right? If the 1PC optimization is hosing up the JCA ManagedConnectionPool ... ?
I have essentially this issue already open with JBoss/RH support, so I'll update that issue with the discovery made here and see where this goes ... maybe we'll just go to production with a DummyXAParticipant ;-)