Re: [jbosscache-dev] Re: Non Blocking State Transfer Status (& Integration with JGroups)
Jason T. Greene wrote:
> This is possible because FLUSH blocks only *multicast* messages, not
> *unicast* messages. This is guaranteed because virtual synchrony
> applies only to group messages.
Ah, ok then I can use flush for the final block.
Great ! Let me and Vladimir know if you have additional requirements on
FLUSH, so we can provide them if needed.
> What happens when A and D pause transactions and C wants to
commit
> TX-5 ? Would, assuming the pause takes longer than the commit, TX-5
> get rolled back ? If that's the case then I think a regular flush
> would not hurt.
It depends on whether C is async or not, and if A and D care about the
TX C is committing (e.g. to a partition A and D are not a participate
in). We don't really want to block C unless C somehow relies on A or D.
Let's assume A, C and D are all part of the same cluster {A,B,C,D,E}.
Would C rollback TX-5 if it can't get an OK from A and D ? I assume A
and D will not send back an OK from the PREPARE phase, right ?
>
>> This however is not a big deal because we can just do this in JBoss
>> Cache using a normal RPC message that flips a gate.
>>
>> In addition, the state transfer and streaming state transfer
>> facilities in jgroups can not be used (since they are designed
>> around blocking the entire group).
>
> No, both state transfer protocols are completely independent from
> FLUSH: they work with or without FLUSH being present.
I could have phrased that better. The problem is that NBST requires a
dialog beyond a single getState/setState. The receiver needs to find a
sender that is available, and it needs to receive main state, then N
tx log transfers, then coordinate a flush, then another tx log transfer.
OK. We should try the following (should work but haven't tried this before):
1. D requests state from A (streaming state transfer)
2. while(TX log size > DEFAULT) --> get log (RPC)
3. START-FLUSH(A,D)
4. get remainder of TX log
5. STOP-FLUSH(A,D)
So step #2 is an RPC. I'm thinking whether we could use state transfer
for step #2 as well: state transfer let's you pass an object to the
state provider, maybe the object could be a switch/boolean deciding
whether to fetch the entire state (#1) or the TX log (#2/#4).
Vladimir, what do you think ? If we do that, state transfer would use a
digest in #1 and #2, but no digest in step #4 (because we're flushed).
Would that work ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat