Julius Stroffek <[EMAIL PROTECTED]> writes: > Hi Saurabh, > >> Correct, at this point the transaction is not committed, this only >> gets committed by the next select statement. > Not only select statement but any other statement... ;-) >> Well the writeLocalRollback_() method calls buildRDBRLLBCK() and >> sends RDBRLLBCK code-point. I am not sure that this approach can be >> used for all the cases. >> Or do we need to implement writeRollback() as a new method to handle >> this particular case >> (accumulatedReadException). Comments/Suggestions please. > Why we need to implement a writeRollback() method? The one similar to > the writeCommit() of the org.apache.derby.client.am.Connection class > is not sufficient? > > The key question is whether the statement with error should (or could) > rollback the active transaction? What are your opinions? > Maybe it may do rollback of the transaction only if the auto commit is > on. However, if the auto commit is off the failed statement will be > executed even the exception will be thrown.
Whereas rolling back the entire transaction doesn't completely match the behaviour of the embedded driver, I think it's the closest we can get as long as we're using DRDA. You could take a look at org.apache.derby.client.am.Statement.checkForStoredProcResultSetCount() which solves a similar problem. It is in general very difficult to get consistent behaviour between embedded and the network client when we have exceptions generated on the client side during or after execution of a statement. -- Knut Anders
