hey it is "markedRolledBack" does it do that?
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
|Sent: Wednesday, October 25, 2000 2:01 PM
|To: jBoss Developer
|Subject: RE: [jBoss-Dev] More DB Test Woes
|
|
|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
|> |
|> |
|> |
|> |
|>
|>
|
|
|
