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
|
|
|
|
