|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
|Sent: Wednesday, October 25, 2000 2:17 PM
|To: jBoss Developer
|Subject: RE: [jBoss-Dev] More DB Test Woes
|
|
| Ah - wait. When Minerva sees a SQLException, it unregisters from
|the transaction with the FAIL flag, and the TxCapsule interprets that as
|meaning the transaction should be marked for rollback.
| So, there are two possibilities. We could not deregister at all
|in this case, which would mean that the bean would be required to catch
|the exception and close the connection, or it would stay open in limbo
|until the GC reclaimed it (if enabled). Or, we could deregister with the
|SUCCESS flag, which would cause the TxCapsule to not mark for
|rollback.
| Looking at the specs, it seems to imply that we should not
|deregister at all here, but rather assume that the application will catch
|the SQLException and close the DB connection properly. Is that the way
|you think it should work?
yes, the *container* asks the service for something and that service says
"barf", then the container knows what to do with the global transaction
associated with it...
Let me know when you are ready (in cvs) thanks man, good work
marc
|
|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
|> |
|> |
|> |
|> |
|>
|>
|
|
|
