[infinispan-dev] PutForExternalRead performance in 5.1

[Mircea Markus]

>> 3. The third and final option is to basically allow PFER to act as non-transactional even if the cache is transactional so that the transaction can be suspended and PFER can do its job as quick as possible (like it did in 5.0 and before). We know PFER is an special operation with particular options, can't we make room for this non-transactional op? This seems to me the best middle ground between a PFER that does its job and it's performant. I've implemented this in https://github.com/galderz/infinispan/commit/d10fee9b2800d75269505953044006a27ba1b44f and both the newly created test and PutForExternalReadTest pass at least (the rest of testsuite needs checking). Mircea, WDYT?
>> 
>> WDYT?
> 
> I am thinking of something evil and wonder what you think about that.
> I am supposing the fail silently code + solution #3.
> 
> tx1                          |   tx2
>                              |   Read data1
> Read data1              |   PFER data1 -> fails silently
Isn't "PFER data1-changed" in tx2 in line above?

>                              |   Commit data1-changed
not that it is impossible, but why would you do both a transactional put and a PFER for the same key? 
> PFER data1 (works?) |
there's no reason for the PFER above not to succeed.
> 
> (sorry if this looks bad I did not major in ASCII-art).
> 
> Now what happens? Do all other tx see the old data1 or the new
> data1-changed? or is this an impossible case ?
the transactions will see the last data written there, which is indeed data1.
> I am having a hard time seeing what would happen in the lap of time
> between the commit of tx2 and the PFER of tx1 (outside of a tx). Like
> which one would win.
last write would win.