There is indeed an additional problem with our java code sample in that we never call
conn.rollback(). Thanks for hinting at that; we’ll fix it.
conn.rollback() should be called whenever an exception is propagating out of the transaction block. It definitely needs to be called if
conn.commit() hasn’t been called; the jdbc docs seem unclear to me on whether it actually has to be called in case
conn.commit() was called (and failed), but it’s probably best to always call it and swallow any exception from the rollback call.
Now, about savepoints. It’s important to understand that crdb does not have general support for savepoints: crdb lets you define a single savepoint
cockroach_restart and releasing this savepoint actually commits the transaction. If the release call succeeds, the transaction is done. A commit call is still required before the conn can accept new statements, but won’t do much. If the commit call fails, that can only mean that the db connection is broken - and so in this case it doesn’t matter much how your code reacts to the commit exception; hopefully jdbc/the database driver you’re using will not let you do anything further with the connection anyway. As I was saying above, you should probably call
conn.rollback() just in case jdbc wants you to do it, and call it a day.
Does this help?