when to roll back a jdbc transaction

Question

I have been reading an interesting statement in http://download.oracle.com/javase/tutorial/jdbc/basics/transactions.html

The interesting part is:

"Catching an SQLException tells you that something is wrong, but it does not tell you what was or was not committed. Since you cannot count on the fact that nothing was committed, calling the method rollback is the only way to be sure."

Is that really so? If I don't call commit but I got an SQLException then can I not count on nothing being committed? What if my program exits without calling commit or rollback? I thought the transaction will be rolled back automatically for me but this statement takes away my certainty.

Answer 1

you can test it out to see what happens.

I would recommend using Spring for this stuff. It will automatically handle your tx rollbacks for you.

Answer 2

Basically any modern database you would consider using in its default isolation level would not exhibit this behavior. But ultimately, what happens down there is out of JDBC's control and for all it knows you might be using Informix 5 or a 1988 Sybase with an adaper layer under the hood.

Hence, from the high level language API specification point of view, they have to make the statement that nothing is guaranteed if you don't use it properly. Basically it's saying that it would not be considered a bug at the JDBC level if the result of abandoning a connection with neither a commit nor a rollback results in some executed statements showing up in the database level. (Usually for most databases we'd consider that bug at the database level, but again, JDBC is a high level API.)