db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Should be a statement with error allowed to do a rollback of the active transaction
Date Wed, 06 Dec 2006 13:05:35 GMT
Julius Stroffek <Julius.Stroffek@Sun.COM> 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

Mime
View raw message