ansaurus

Question

Are there SqlExceptions which throw but commit their data anyway?

Answer 1

+1 A:

if this thing is entirely possible at all in the first place?

Yes it is possible. It depends what your transaction management code does in the exception case. For example:

Connection connection = ConnectionFactory.create();

try {
    DoWorkOn(connection);
}
catch (Exception e) {
    Log.Message("SQL Problem", e);
}
finally {
    connection.commit();
}

... would always try to commit. This behaviour is built in to some well known transaction management libraries (J2EE specifies this behaviour for application exceptions).

I'm less familiar with .NET - if you post a full stack trace somebody might be able to give you a better answer based on the transaction management software in use.

richj 2010-04-29 21:17:55

I edited it to include a stack trace. Weird. Doesn't make as much sense if it signals a failure through an exception but commits anyway.

Jonn 2010-04-30 05:00:50

In J2EE it's to do with reusing a connection at a transaction boundary between Enterprise Java Beans (e.g. with the REQUIRED transaction attribute). If the second EJB throws an exception, the first EJB might want to catch the exception and retry or recover so that the transaction succeeds despite the exception. If the exception caused the transaction to be marked for rollback then it wouldn't be possible to code this type of retry/recovery behaviour.

richj 2010-04-30 07:37:52

Thanks for the stack trace. Unfortunately it doesn't tell me as much as I had hoped. I was hoping for a clue that would point to the transaction manager class that performs the commit. With that information we could either read the documentation (if it's from a third party library) or look at the code (if it's in-house code).

richj 2010-04-30 07:48:53

ansaurus

tags:

views:

answers:

Are there SqlExceptions which throw but commit their data anyway?

related questions