Hi, Re: https://issues.jboss.org/browse/ISPN-1615, https://issues.jboss.org/browse/ISPN-1617 and http://lists.jboss.org/pipermail/infinispan-dev/2011-November/009577.html I think in Infinispan 5.1, the fact that caches are either transaction or not transactional are affecting the functionality and performance of operations such as putForExternalRead(). The point of PFER is to make data available to other nodes and transactions which has just been read from the database, without blocking, ignoring failures…etc. This operation makes most sense when autoCommit is false and there's an external transaction going on, i.e. Hibernate 2LC. As shown in ISPN-1617, this does not work (Note: currently I have 2LC set to autoCommit=true to make this work but it's not performant as indicated by Slorg1). So, to make this work, we can do three things: 1. As Mircea suggested, we could start a new transaction for PFER after suspending the on-going one. Apart from this being wasteful (suspend and start a new tx) it's pointless because pFER is FORCE_ASYNCHRONOUS operation, so we're ignoring any failures in other nodes to apply the data.

2. Another option is to avoid suspending the transaction. Ever since https://issues.jboss.org/browse/ISPN-1556 was implemented, a failure within a transaction when FAIL_SILENT is on won't rollback the tx. Not suspending the tx has the advantage of not being wasteful from a tx management perspective. The problem though is that PFER won't be applied until the external tx has been commited, so it delays this operation.

On top of this, I have the feeling that if the cache is configured with SYNC, this PFER might be become 2PC (mircea, can you clarify?)

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/d10fee9b2800d752695059530440... and both the newly created test and PutForExternalReadTest pass at least (the rest of testsuite needs checking). Mircea, WDYT?

Hi, See question below, 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                              |   Commit data1-changed PFER data1 (works?) | (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 ? 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.

Hi, See question below, On Thu, Dec 15, 2011 at 03:28, Galder Zamarreño <galder(a)jboss.org&gt; wrote: > Hi, > > Re: https://issues.jboss.org/browse/ISPN-1615, https://issues.jboss.org/browse/ISPN-1617 and http://lists.jboss.org/pipermail/infinispan-dev/2011-November/009577.html > > I think in Infinispan 5.1, the fact that caches are either transaction or not transactional are affecting the functionality and performance of operations such as putForExternalRead(). > > The point of PFER is to make data available to other nodes and transactions which has just been read from the database, without blocking, ignoring failures…etc. > > This operation makes most sense when autoCommit is false and there's an external transaction going on, i.e. Hibernate 2LC. As shown in ISPN-1617, this does not work (Note: currently I have 2LC set to autoCommit=true to make this work but it's not performant as indicated by Slorg1). > > So, to make this work, we can do three things: > > 1. As Mircea suggested, we could start a new transaction for PFER after suspending the on-going one. Apart from this being wasteful (suspend and start a new tx) it's pointless because pFER is FORCE_ASYNCHRONOUS operation, so we're ignoring any failures in other nodes to apply the data. > > 2. Another option is to avoid suspending the transaction. Ever since https://issues.jboss.org/browse/ISPN-1556 was implemented, a failure within a transaction when FAIL_SILENT is on won't rollback the tx. Not suspending the tx has the advantage of not being wasteful from a tx management perspective. The problem though is that PFER won't be applied until the external tx has been commited, so it delays this operation. On top of this, I have the feeling that if the cache is configured with SYNC, this PFER might be become 2PC (mircea, can you clarify?) > > 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/d10fee9b2800d752695059530440... 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 | Commit data1-changed PFER data1 (works?) | (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 ? 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. Thank you, Regards, L.P. -- Please consider the environment - do you really need to print this email ?

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.

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)

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