[infinispan-dev] IRC meeting

[Pedro Ruivo]

Hi,

On 07-05-2012 13:40, Dan Berindei wrote:
> On Wed, May 2, 2012 at 4:43 PM, Pedro Ruivo<pruivo at gsd.inesc-id.pt>  wrote:
>> Hi,
>>
>> On 5/2/12 1:54 PM, Dan Berindei wrote:
>>> One question I haven't been able to figure out is about the unpaired
>>> prepares and commits that arrive to a joiner before the PREPARE_VIEW
>>> command. (Unpaired because the joiner didn't receive the corresponding
>>> commit/prepare.) I think this could even happen for commit commands
>>> that arrive after PREPARE_VIEW. What happens to those?
>> if the prepare arrives before the PREPARE_VIEW, you can discard it,
>> because it will receive the state that already contains the updates
>> values of that transaction
>>
> Ok
>
>> for the commit/rollback, it can be a little more complicated. My idea is
>> to tag the commit/rollback command with the ViewId of when the prepare
>> was received. And then do the following (in the JoinNode)
>>
> Interesting, it's quite similar to what we had in mind for NBST,
> except we wanted to give each command its own view id (as opposed to a
> view id per transaction).
>
>> 1) if prepare, commit or rollback is delivered before PREPARE_VIEW:
>> discard it (same reason above)
>>
> Since the commit/rollback can be OOB, I think it's possible for a
> commit to arrive before the PREPARE_VIEW even if the prepare was sent
> after the PREPARE_VIEW. So if we can't discard *all* commits, as some
> of them might be paired with prepares that will only arrive
> afterwards. I think we need to treat commits/rollbacks the same way,
> whether they arrive before the PREPARE_VIEW or after.
I think that it can't happen, because if you send the commit/rollback in 
the view X, then all the nodes have already executed the PREPARE_VIEW 
for X. In this case, it will be delivered after the PREPARE_VIEW.
>> 2) if commit or rollback is delivered after the PREPARE_VIEW, then you
>> check the ViewId in the commit / rollback. In this case:
>> 2.1) if the commit/rollback.viewId<  PREPARE_VIEW.newViewId, then you
>> can discard it because it corresponds to a transaction delivered before
>> the PREPARE_VIEW.
> The same with prepares, I assume.
yes. it needs to retry the prepare to include the new node :)
>
>> 2.2) Otherwise, you must hold it until the COMMIT/ROLLBACK_VIEW is received.
> So I guess there must be a latch for the state transfer "transaction"
> that the regular commit/rollback commands can wait on after all...
We can use the State Transfer Lock or it does not fit in this model?
>
>> 2.2.1) if the ROLLBACK_VIEW is received, then you are in case 1) and you
>> can discard the command.
>>
> The command could have been sent after the next PREPARE_VIEW (which
> retries installing the view that includes this joiner), so I think we
> need to check the transaction's view id against the current view id.
ok
>
>> What do you think? Any other ideas?
>>
> Looks good to me. At some time we'll need to extend it to work in
> distributed mode, but that will only be necessary for TOM.
I think that it will work fine in distributed mode without any changes :)

Cheers,
Pedro
>
> Cheers
> Dan
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev