Necessity for deadlock handling

Question

Being less than awfully bright, I didn't realise until very recently that deadlock handling is most likely essential in all but the simplest applications built on DB XML. This is no criticism of DBXML, which is wonderful, just a learning issue.
I wondered if it'd be worth adding an FAQ entry to that effect together with a hint or two about how best to handle it (I guess that'd be per-language). It's probably not a frequently asked question, but it ought to be.
In Java I refactored all my transaction-surrounded code blocks into method-local class instances, passed as a parameter to a static MyXmlTransactionImpl.wrapWithDeadlockRetry() method.
Also, I used ThreadLocal for XmlTransaction and XmlQueryContext objects (in my app, a thread that starts a transaction also finishes it).
I'd like to know approaches others have taken in Java, but also to help others be aware from day 1 of their coding that they shouldn't remain ignorant of this coding requirement.

Answer 1

I thought 3 pieces to it (sorry about formatting, couldn't see any way to make it readable):
1. Interface (to be implemented by method-local anonymous classes for the most part):
public interface SleepycatXmlTransactionWrapper<T> {
     public T run() throws Exception;     
2. Class with static method and static ThreadLocal property which actually does the transaction + deadlock retries:
public class SleepycatXmlTransaction {
     public static final int DEADLOCK_RETRIES = 3;
     private static ThreadLocal<XmlTransaction> tx = new ThreadLocal<XmlTransaction>();
     private static void createTransaction() {...blah...}
     private static void commitTransaction() {...blah...}
     privatet static void abortTransaction() {...blah...}
     public static <T> T wrapWithDeadlockRetry( SleepycatXmlTransactionWrapper<T> txw) throws Exception {
          Exception cause = null; // Wrapped in a TeqloException if retries fail
          T returnValue = null;
          for ( int i = 0; i < DEADLOCK_RETRIES; i++) {
               try {
                    createTransaction(); // static method uses ThreadLocal XmlTransaction
                    returnValue = txw.run(); // Do the work, return whatever's needed
                    commitTransaction(); // ditto
                    return returnValue; // ditto
               catch ( Exception e) {
                    // Abort, but continue in the loop if our transaction was deadlocked
                    cause = e;
                    abortTransaction();
                    if ( isDeadlock( e)) {
Loggers.XML_RUNTIME.info( "Transaction deadlock " + (i + 1));
Thread.yield(); // Give other threads a chance before we retry
                         continue;
                    else
                         throw cause;
          // We're out of retries - too bad
          throw new FoobarException( "Transaction failed after " + DEADLOCK_RETRIES + " retries");
3. Use by creating method-local class implementing SleepycatXmlTransactionWrapper and passing to the static SleepycatXmlTransaction.wrapWithDeadlockTransaction(...) method:
     public Vector<String> foo( final String bar) throws SomeException {
          Vector<String> result = null;
          try {
               result = SleepycatXmlTransaction.wrapWithDeadlockRetry( new SleepycatXmlTransactionWrapper<Vector<String>>() {
                    public Vector<String> run() throws Exception {
                         ...all your sleepycat stuff...
          catch ( Exception any) {
               blah blah
          return result;
The parameterized method-local classes are useful if (like me) you've done a lot of code all terribly nicely wrapped in transactions but completely omitted to deal with deadlock handling. Refactoring those blocks of code into the form above is very dull, but pretty quick if you're rapid with cut and paste.
I hope this is useful to someone. I'm sure there are better solutions.