[infinispan-dev] IRC meeting

[Dan Berindei]

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.

> 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.

> 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...

> 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.

> 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.


Cheers
Dan