[infinispan-dev] PutForExternalRead performance in 5.1

[Slorg1]

Hi,

On Fri, Dec 16, 2011 at 11:59, Mircea Markus <mircea.markus at jboss.com> wrote:
>>
>> 1. tx2 read data1.
>> 2. it performs a PFER with fails for some random reason. With the new
>> code you put in, that does not rollback the tx and continue as though
>> nothing happened.

> it's not only with the new code, that's part of PFER's contract.
> Or do you need something that would force an invalidation before the transaction commits?

I do not understand what you are saying here.


>> At the same time, tx1 reads the same data1.
>> 3. tx2 commits changes to data1 (now called data1-changed).
>> 4. tx1 after reading the data, does a PFER of what it just read: data1
>> (the unchanged version)

> why does tx1 try to update a pice of data it hasn't changed...

Where does tx1 says it does anything with data1? All I listed here is
that tx1 reads it and does a PFER, it may or may not change it, that
changes nothing to the issue here, either way stale data may be stored
in the cache.

>> After 4 no one will see 'data1-changed' they will all see 'data1',
>> effectively holding onto stale data, or am I wrong?

> yes. Same thing would happen though even if PFER is guaranteed to succeed: in the case tx1 reads data1 before the PFER, it would keep it in it's tx
> context and the invalidation message doesn't remove data from the tx context, but only from the main node's storage.

Not really because if PFER is transactional then in the first place
tx2 cannot change data1 without PFER to succeed. Second failure on tx1
to do whatever (since it is going to try to commit with stale data)
will not leave bad data in the cache for all other subsequent
transations to read.

Let me know if we should take that to IRC.

Regards,

L.P.

-- 
Please consider the environment - do you really need to print this email ?