Transaction manager silently aborts transaction commit due to write skew conflicts with other concurrent TX but does not throw RollbackException from TransactionManager.commit() as mandated by JTA spec. This only happens for a non-transactional cache. Tx for non-transactional caches are supported via DummyTransactionManager/DummyTransaction which seems to behave quite differently than JBoss TM and the JTA spec.

I've done a simple test. One non-transactional cache with batching, optimistic locking, simple versioning and write skew check. I use explicit manual transaction demarcation. N threads attempt to remove the same key concurrently and I count how many succeeded to remove (ie. remove(key,value) returned true) and also commit the TX successfully. I expect 1 but it turns out there are more successes.