Question

I have the following code (OLE = OptimisticLockException)…

public void outer() {

  try {
    middle()
  } catch (OLE) {
    updateEntities();
    outer();
  }
}

@Transactional
public void middle() {
  try {
    inner()
  } catch (OLE) {
    updateEntities();
    middle();
}

@Transactional
public void inner() {
  //Do DB operation
}

inner() is called by other non-transactional methods which is why both middle() and inner() are transactional. As you can see, I deal with OLEs by updating the entities and retrying the operation.

The problem I’m having is that when I designed things this way I was assuming that the only time one could get an OLE was when a transaction closed. This is apparently not the case as the call to inner() is throwing an OLE even when the stack is outer()->middle()->inner().

Now, middle() is properly handling the OLE and the retry succeeds but when it comes time to close the transaction it has been marked rollbackOnly by Spring. When the middle() method call finally returns the closing aspect throws an exception because it can’t commit a transaction marked rollbackOnly.

I’m uncertain what to do here. I can’t clear the rollbackOnly state. I don’t want to force create a transaction on every call to inner because that kills my performance. Am I missing something or can anyone see a way I can structure this differently?

EDIT: To clarify what I’m asking, let me explain my main question. Is it possible to catch and handle OLE if you are inside of an @Transactional method?

FYI: The transaction manager is a JpaTransactionManager and the JPA provider is Hibernate.

Answer 1

Well, after trying for a while, I guess the answer is no. Anytime you catch an OLE you have to make sure that you start a new transaction. I went ahead and restructured my code so that middle didn’t have to catch the OLE.