[jbosscache-dev] Re: Non Blocking State Transfer Status (& Integration with JGroups)

[Bela Ban]

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