Hi,
On 07-05-2012 13:40, Dan Berindei wrote:
On Wed, May 2, 2012 at 4:43 PM, Pedro
Ruivo<pruivo(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev