Marc,
You're the second one to say this, but I don't get it. When I do
a case-insensitive search through org.jboss.minerva.* for "rollback", it
rolls back:
- in JDBCConnectionFactory which is not used by jBoss
- in XAConnectionFactory when you return a connection to the pool and
there is no current transaction
- in ConnectionInPool which is not used by jBoss
- in XAClientConnection when you call "con.rollback" in your bean
- in XAConnectionImpl which is called by #2 above
- in XAResourceImpl when a commit fails, or when the resource is rolled
back
Really, to my knowledge, Minerva never rolls back (or marks for
rollback) in the event of an error. When you generate a SQLException, it
either ignores it or marks the connection to be dropped when it is
returned to the pool, but does not call into the TM or something to mark
it for rollback.
Aaron
On Tue, 24 Oct 2000, marc fleury wrote:
> Ok get ready Aaron, get ready to be crucified....
>
> So we just spent 4 hours with Sebastien tracking down a bug that talks
> Aaron/Ole and was quite nasty...
>
> so when jaws tries to read the MaxValue that he can't set in the db test he
> chokes on the read (which can be quite normal) and goes on reading with
> other formats until he tries a getObject on the result.
>
> Now the interesting bit regarding you is that Minerva takes the courageous
> decision to "rollback" the transaction because of a JDBC exception... this
> is clearly bad as jdbc exception are normal part of reading with jaws...
> maybe there is a better way to do it but for our purposes, I am not sure the
> "pool manager" should take the decision to "rollback" anything, or should
> he?
>
> Ok the f*cked up thing was that the tx was then propagated with
> Tx-marked-rollback and for some "JTA" exception Ole had added a nice check
> that basically disables the registration of the synchronization callback to
> the infrastructure, so that in a very screwed up way the container never was
> notified of the transaction demarcation.... Ole... that decision to not
> notify the container on transaction demarcation is a serious one... I will
> say "mybad" in the fact that I did not catch something like that before, but
> transaction demarcation is deep in the container and disabling it for
> "warning" is dangerous. Again I know you notified us (afaik), so I guess it
> is OK, :)
>
> BUT GUYS that one was nasty to catch since it was 2 bugs on top of one... ok
> we have a "fix" which basically is to remove the Ole "check" but it remains
> Aaron that I don't think Minerva should rollback transactions in his corner,
> that decision is up to the application or container. At any rate it will
> show that being bearer of bad news usually means bad news for one-self ;-).
>
> Let me know what you guys see there in both cases as we need to do it
> right...
>
> Ok the fix in CVS works with our tests (doesn't lock up anymore)
>
> marc
>
>
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> |Sent: Tuesday, October 24, 2000 9:57 AM
> |To: jBoss Developer
> |Subject: [jBoss-Dev] More DB Test Woes
> |
> |
> | Hate to be the bearer of bad news, but... I'm getting another
> |lockup during the DB test. Can you guys (who are working on the locking
> |and stuff) build the current CVS of jBoss and the test suite, and run the
> |dbtest with everything exactly as it is in CVS? That should run it
> |against Hypersonic, and fail when it tries to write the extreme Longs.
> |After it fails, I get a bunch of messages like:
> |
> |[AllTypes] LOCKING-WAITING (TRANSACTION) for id seb ctx.hash 3593899
> |tx:TransactionImpl:XidImpl:[B@789869
> |
> | Even worse, after I hit Ctrl-C, when the server tries to shut
> |down, it gets more of those messages and does not exit. There's no way to
> |stop it without killing the process. This is unfortunate.
> |
> |Aaron
> |
> |
> |
> |
>
>
