[infinispan-dev] JCache implementation documentation

[cotton-ben]

/> 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.