Handling JacisStaleObjectExceptions

[fullben]

In my project, there are currently a few services which use JACIS transactions to manipulate data stored in multiple JacisStores based on requests made by clients.
Every now and then, one of the transactions will result in a JacisStaleObjectException (and a rollback), as the high frequency of the client requests causes concurrent modification attempts on the same objects.
As far as I can tell, there appear to be two options for handling this issue:

1. At the end of each transaction, check all modified objects for staleness (store.isStale(key)) and update any stale objects. I probably would have to run this as an atomic operation to reduce the likeliness of another transaction making modifications in the meantime. But even then the transaction may still fail on commit.
2. Retrying the transaction. I've seen the container.withLocalTxAndRetry(Runnable r, int retries) method, but this is unsuitable for my purposes, as my transactions usually produce a return value; I would need something like container.withLocalTxAndRetry(Supplier<T> s, int retries).

Are there any other options for dealing with this issue?

Edit:
I've been playing around and implemented a transaction utility class, would love to hear your thoughts on it:
https://gist.github.com/fullben/c37fce0cbbefc680e27b50a5eb6cd618

[JanWiemer]

Generally retrying the whole transaction is the solution for stale object exceptions when using optimistic locking (similar e.g. in hibernate...). I also always use a helper class starting the transaction, executing a task and finally committing the transaction. This helper class also cares about the retry. The helper class looks similar to your suggestion (I usually add an increasing delay between the retries). I implemented the helper class outside the store since I usually use it with global JTA transactions and the helper class is more general.

Anyway I will think about adding a helper class (or method) doing the same for local transactions...
See: #28 (comment)

[fullben]

Alright. I think such a helper class would make a great addition to the library.

How do you usually implement the delay between individual tries? Thread.sleep(millis)?

[JanWiemer]

Usually I start with some rule like: the first retry is done immediately, the second with 50 millis delay and for each following the delay is duplicated. If this causes issues the rule may be adapted, but usually it fits.

You may try the solution in 5f63425
(See issue #28)

[fullben]

Alright, thx for the advise! I like your TransactionExecutor approach, looking forward to that release :)