/> QUESTION: Is there a native-Infinispan config to indicate an OPTIMISTIC > policy (btw, this is not yet provided for via JSR-107 API) ? I.e. does > Infinispan allow an OPTIMISTIC READ_COMMITTED isolation config that would > result in the capability for TX_THR_2 to physically read the un-committed > value @t=2 ($6) but would not allow TX_THR_2 to commit its transaction > unless TX_THR_1 had already committed its @t=1 mutation?
We do indeed support optimistic locking within Infinispan: <LINK> But, it won't work the way you mention. T2 won't read the un-committed value that T1 updated. T2 will read the last committed value, work with it, and when the transaction commits, it will fail because since the start of the transaction, T1 has modified the entry, and hence, the value T2 was operating on was outdated. Cheers, / *Thanks Galder. This is another perfectly acceptable (but indeed a little bit different) technique for accommodating DIRTY_READ intolerant transactional caching use cases OPTIMISTICALLY. Thanks again. -Ben* -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-JCache-implementation-documentation-tp4026877p4026975.html Sent from the Infinispan Developer List mailing list archive at Nabble.com. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
