Comment by maxdamantus

I wasn't thinking of JDBC SQL transactions specifically, but sure, different APIs can denote retriable transaction failures differently. Instead of:

  if (!tx.commit()) { continue; }

you do:

  try { conn.commit(); } catch (SQLTransactionRollbackException e) { continue; }

and the principle still applies. The simplest solution still involves a `continue` within the `finally` block.

Whether it's a good idea to actually do this directly using SQL connections is another question .. SQL databases usually use pessimistic locking, where the transaction failures are actually "deadlocks" that are preferably avoided through careful ordering of operations within the transaction (or more commonly, YOLOing it using an isolation level that allows read anomalies). Without going into all the details, this probably has a large influence over the design of the SQL APIs you're referring to.