[infinispan-dev] TOB/TOA integration

[Paolo Romano]

Hi all,

with Pedro we have been reasoning on the integration of TO-based 
replication protocols, and a few questions popped out.

We may be missing something here, but it seems that the current NBST 
implementation is still not providing support for pending transactions, 
namely transactions that are prepared but not yet committed at the time 
in which the node receives a state transfer request. We have tried to 
figure out how you plan to do this by checking the design document:

https://community.jboss.org/wiki/Non-BlockingStateTransferV2

but we still have some doubts. The relevant extract seems to be the 
following:

      1.3 For new segments, it asks one of the current owners (the 
donor) for the transactions and locks.
      1.4 The donor only replies with the transactions and locks after 
it has installed the new toplogy. We need this to make sure a proper 
pending CH is also installed on the donor and request forwarding to the 
new pending owners is in place (forwarding is explained in request 
handling section).
      1.5 The transactions and locks are applied on acceptor.
      1.6 The acceptor requests new data segments from donor asynchronously.
      1.7 Unblock all incoming commands. We are now prepared to process 
commands although some data segments are still flowing in.

In point 1.7, you say that you can already process commands for data 
segments that a node has not received yet. However, if the command is, 
say, a prepare for a key in a missing data segment and the transaction 
is requesting a validation (write-skew check), you would still need to 
block as you need the most updated data version to validate it. Are we 
getting it right?

Also, it seems that point 1.5 has not been coded yet. We are asking 
this, as these functionalities are likely to be useful also for the NBST 
version used by TO-based replication protocols. Thus, it'd probably be 
better to wait for these parts to be stable and re-use them, instead 
than implementing them from scratch and end-up possibly with 
conflicting/incompatible implementations. When do you plan to have this 
functionality implemented?

Finally, I wanted to point out that Roberto and Sebastiano have been 
thinking about an alternative version of the NBST, which should further 
reduce the blocking time of transactions. They're currently still at the 
design stage, and are working to prepare a document that we would like 
to share with you to get feedback/comments etc. We plan to have a draft 
of the algorithm by Sept. 20.

Cheers,

     Paolo

PS: I'll be travelling starting tomorrow and during next week, so I may 
not be responding to emails very quickly.


On 7/25/12 12:16 PM, Dan Berindei wrote:
> Sounds good to me, we should have a little more breathing room after 
> the NBST alpha to look at the state transfer integration.
>
> Cheers
> Dan
>
>
> On Tue, Jul 24, 2012 at 6:08 PM, Mircea Markus 
> <mircea.markus at jboss.com <mailto:mircea.markus at jboss.com>> wrote:
>
>     Hi guys,
>
>     I've just had a chat with the CloudTM team(CC) around the
>     integration of TOB/TOA[1] into Infinispan. Here are some points:
>     - the TOB and TOA code has been reviewed in detail by us. The only
>     part missing is the state transfer integration
>     - there's not a lot of sense in integrating TOB/TOM over the
>     existing state transfer as we would not back port that to 5.1 and
>     it would be dropped in 5.2
>     - CloudTM would rebase the TOB/TOA work on top of the alpha
>     NBST[2](ATM planned at the end of  next week/3 Aug) and we'll
>     integrate that
>     - first releases of the TOB/TOA would be marked as experimental in
>     5.2
>
>     How does that sound?
>
>     Cheers,
>     Mircea
>
>     [1] TOA used to be referred to as TOM (M from multicast). In
>     JGroups terminology that's an Anycast, so we decided to be
>     consistent with that and use TOAnycast.
>     [2] https://community.jboss.org/wiki/Non-blockingStateTransfer
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120914/e144f5a5/attachment.html