that's how is working. The state is persisted in a centralized database that is using optimistic locking. So, two threads can access to the state, but if they want to change it one of them will fail.. and you will need to retry that, the other one will be applied, keeping the state consistent all the time.
When the unlucky thread fails, will it retry automatically?
I will have to test this scenario. (Not that I don't trust you ;-) It is absolutely crucial to us that all actions the failing thread takes (JMS dequeue/queue, database, etc) are rolled back completely and then resumed and replayed with the updated state from the other thread.
NO, it will not automatically retry but as you mention you can do that with JMS, where you can configure the number of retries.