[infinispan-dev] Fwd: infinispan-dev Digest, Vol 56, Issue 24

[Ryan Emerson]

Hey guys, thank you for taking the time to watch my talk.


> Thanks for sharing the recording. Finally I've found out what's the
> purpose of total order protocol, although the drawbacks with WSC look
> pretty limiting. I'd really like to see the impact with WSC on, but that
> would require Infinispan itself as the main problem TOA is trying to
> solve is degraded performance due to deadlocking.
>

The original paper [1] that describes the TOA algorithm, and its
integration with Infinispan, has extensive performance figures comparing
2PC with Total order based commit.  The results of their experiments show,
that with the write/skew check in place, throughput increases and latency
decreases when using the Total Order based commit in clusters containing
six or more nodes.  The transaction abort rate is similar to that of 2PC
(when write/skew check is used).



> My main questions is about the ordering box size - if I understand that
> correctly, the ordering box consists of several physical machines.Then,
> what's the way to get the synchronized GSN from them? Is this the same
> as with regular TOA, taking the highest timestamp from all of the nodes?
> Or is there any internal synchronization within the ordering box?
>

The synchronised GSN is maintained using internal synchronisation between
the box members.  Internal synchronisation is used, because we want the
order box approach to be independent of the underlying total order
protocol.  Below is a brief description of how the GSN is maintained.

All box members start with a GSN value of 0.  Upon receiving an ordering
request from an Infinispan node, a box member sends a totally ordered
message (containing the id of the infinispan message that requires
ordering) to all box members (including itself).  Because this box message
is totally ordered, it is guaranteed that all box members receive the box
message in the same order, therefore each box member assigns the same GSN
to the infinispan message associated with this box message. As soon as the
contacted box member has delivered its own message it will know the GSN of
the infinispan message, and therefore a response (containing the GSN) can
be sent to the infinispan node that requested ordering.

My intention is to prepare a document explaining in detail how our system
works, which I will distribute to the mailing list at some point next week.


Ryan

[1] http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6133071


> Anyway, I like the idea of centralizing things, as the problem itself is
> centralized. And as my parallel systems teacher said, solving
> centralized problem in distributed fashion usually causes more trouble
> than it's worth.
>
> Radim
>
> On 11/15/2013 12:29 PM, Paul Robinson wrote:
> > All,
> >
> > Here's the recording from the Newcastle JBug...
> >
> > http://www.youtube.com/watch?v=04qNcovQKLA
> >
> > I've also added Ryan to the CC, in case you have any specific comments
> > you want to direct his way.
> >
> > Paul.
> >
> > --
> > Paul Robinson
> > Web Service Transactions Lead
> > paul.robinson at redhat.com <mailto:paul.robinson at redhat.com>
> >
> > JBoss, a Division of Red Hat
> > Registered in England and Wales under Company Registration No. 03798903
> > Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson
> > (US), Paul Hickey (Ireland)
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss DataGrid QA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131115/d647d585/attachment.html