[infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation

[Dan Berindei]

On Mon, Jun 17, 2013 at 7:00 PM, Mircea Markus <mmarkus at redhat.com> wrote:

>
> On 17 Jun 2013, at 16:11, Dan Berindei <dan.berindei at gmail.com> wrote:
>
> > > I think that, given that the local node is not owner, the lock
> acquisition is redundant even for pessimistic caches.
> > > Mind creating a test to check if dropping that lock acquisition
> doesn't break things?
> >
> > I created a JIRA with low priority since it does not affect the
> > transaction outcome/isolation and I believe the performance impact
> > should be lower (you can increase the priority if you want).
> >
> > https://issues.jboss.org/browse/ISPN-3237
> >
> > If we don't lock the L1 entry, I think something like this could happen:
>
> There is a lock happening *without* L1 enabled.
>
>
Nope, tx1 doesn't lock k1 on B because it doesn't do a put(k1, v3) - it
only reads the value from B. So even if tx2 does lock k1 on B, it doesn't
add any synchronization between tx1 and tx2.

But tx1 does write the entry to L1 on A, so it should acquire an "L1 lock"
on A - and tx2 should also acquire the same lock.



>  >
> > tx1 at A: remote get(k1) from B - stores k1=v1 in invocation context
> > tx2 at A: write(k1, v2)
> > tx2 at A: commit - writes k1=v2 in L1
> > tx1 at A: commit - overwrites k1=v1 in L1
> >
> >
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130618/b7e7cff6/attachment-0001.html