Thanks for the feedback and clarifications Dan ! Comments inline...
>> Over the last couple of days, I've exchanged a couple of emails with the >> Cloud-TM guys, and I'm more and more convinced that their total order >> solution is the simpler approach to (1) transactional updates and (2) >> state transfer. They don't have a solution for (2) yet, but I believe >> this can be done as another totally ordered transaction, applied in the >> correct location within the update stream. Or, we could possibly use a >> flush: as we don't need to wait for pending TXs to complete and release >> their locks, this should be quite fast. >> > > Sounds intriguing, but I'm not sure how making the entire state > transfer a single transaction would allow us to handle transactions > while that state is being transferred. We're discussing 2 scenarios, one being the use of flush (but short-lived as we don't have any locks in play) and the other being Pedro's proposal of a start-state TO-cast (shipped with a keys set), followed by a state transfer. Transactions with any keys in the key set are queued and applied in order after the state transfer is done (signalled with abother stop-state TO-cast). If you have anything to add, let's discuss it on the other thread. >> So my 5 cents: >> >> #1 We should focus on the total order approach, and get rid of the 2PC >> and locking business for transactional updates >> > > The biggest problem I remember total order having is TM transactions > that have other participants (as opposed to cache-only transactions). > I haven't followed the TO discussion on the mailing list very closely, > does that work now? No, I don't think that's addressed by TOM, good point in favor of having 2 (or more) approaches to partial replication and state transfer ! I think a lot of systems would still benefit from TOM though as there are no external participants, for instance session replication: it uses an Infinispan batch to ship session updates to the session owners, and there are no other participants (as a matter of fact, this is not even a JTA transaction anyway). > Regarding state transfer in particular, remember, non-blocking state > transfer with 2PC sounded very easy as well, before we got into the > details. True :-) >> #2 Really focus on the eventual consistency approach >> > > Again, it's very tempting, but I fear much of what makes eventual > consistency tempting is that we don't know enough of its > implementation details yet. True again... > Manik has been investigating eventual consistency for a while, I > wonder what he thinks... Yep - Manik, do you have any status update on eventual consistency ? -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
