On Nov 18, 2013, at 12:42 PM, Dan Berindei <[email protected]> wrote:
> > > > On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreño <[email protected]> wrote: > > On Nov 14, 2013, at 1:20 PM, Pedro Ruivo <[email protected]> wrote: > > > Hi, > > > > Simple question: shouldn't PFER ensure some consistency? > > > > I know that PFER is asynchronous but (IMO) it can create inconsistencies > > in the data. the primary owner replicates the PFER follow by a PUT (PFER > > is sent async log the lock is released immediately) for the same key, we > > have no way to be sure if the PFER is delivered after or before in all > > the backup owners. > > > > comments? > > Assuming that PFER and PUT happen in the same thread, we're normally relying > on the JGroups sequence of events to send the first, wait no response, and > then send the second put. That should guarantee order in which puts are > received in the other nodes, but after that yeah, there's a risk that it > could happen. PFER and PUT for a given key normally happen in the same thread > in cache heavy use cases such as Hibernate 2LC, but there's no guarantee. > > I don't think that's correct. If the cache is synchronous, the PUT will be > sent as an OOB message, and as such it can be delivered on the target before > the previous PFER command. That's regardless of whether the PFER command was > sent as a regular or as an OOB message. ^ Hmmmm, that's definitely risky. I think we should make PFER local only. The fact that PFER is asynchronous is nice to have. IOW, if you read a value from a database and you want to store it in the cache for later read, the fact that it's replicated asynchronously is just so that other nodes can take advantage of the value being in the cache. Since it's asynchronous some nodes could fail to apply, but that's fine since you can go to the database and re-retrieve it from there. So, making PFER local only would be the degenerate case, where all nodes fail to apply except the local node, which is fine. This is better than having the reordering above. In a chat I had with Dan, he pointed out that having PFER local only would be problematic for DIST mode w/ L1 enabled, since the local write would not invalidate other nodes, but this is fine because PFER only really makes sense for situations where the Infinispan is used as a cache. So, if the data is in the DB, you might as well go there (1 network trip), as opposed to askign the other nodes for data and the database in the worst case (2 network trips). PFER is really designed for replication or invalidation use cases, which are precisely the ones configured for Hibernate 2LC. Thoughts? > > > Cheers, > > > > > Pedro > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > [email protected] > twitter.com/galderz > > Project Lead, Escalante > http://escalante.io > > Engineer, Infinispan > http://infinispan.org > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
