So what you mean to say that rolling back of transaction should be
dependent on the application's behavior. If my understanding is correct,
then in DERBY-2017, the way I tried to handle the case in not correct.
How this case should be handled then?
Saurabh
Daniel John Debrunner wrote:
Julius Stroffek wrote:
In this case, user may have troubles - for example when executing an
sql script through ij with autocommit off - the part of the
transaction code would be rollbacked and part of the code will be
committed by the following commit.
ij is not intended as an application tool to manage transactions, it's
a simple scripting tool.
I believe Derby works in this respect as all other relational
databases do and follows the SQL standard (section 4.33.5). The
statement rollback allows applications to make different decisions
within a transaction context without having to re-start from scratch
each time, e.g. if an update to a stock item violates the constraint
that the stock level should never be less than zero, then the
application can take an alternate path to issue a statement that
results in a back-order.
Dan.
When an error is produced by the transaction transaction may get to
the abort state and the following commit or rollback will always
perform a rollback of the transaction. This ensures that the whole
transaction would be rollbacked. The statements following after the
statement with the error will always throw an exception (something
like the "Transaction is in abort state").
Cheers
Julo
Daniel John Debrunner wrote:
Some exceptions are transaction level, such as deadlock or lock
timeout, thus an error from a statement can rollback the transaction.
