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