-
1. Re: Controlling state transfer behavior with BuddyReplicatio
manik May 8, 2006 11:03 AM (in response to brian.stansberry)I presume you're referring to a 'shared' persistent store, in which case it makes sense. In fact, with a shared persistent store, why bother with buddy replication at all?
-
2. Re: Controlling state transfer behavior with BuddyReplicatio
brian.stansberry May 8, 2006 11:17 AM (in response to brian.stansberry)"manik.surtani@jboss.com" wrote:
I presume you're referring to a 'shared' persistent store, in which case it makes sense. In fact, with a shared persistent store, why bother with buddy replication at all?
Are you talking about this statement?If the buddy can retrieve state from a persistent store, it isn't requirement to transfer the in-memory copy.
If so, I really meant an unshared store (you're right - BR with a shared store is silly). I meant that if all state is in a persistent store on the DataOwner, and that state is transferred to the buddy as part of a persistent state transfer, then there is no requirement to do an in-memory state transfer as well. That's a configuration choice up to the user; depends on whether they want the in-memory backup tree to be cold or hot. This is no different from the non-BR case. -
3. Re: Controlling state transfer behavior with BuddyReplicatio
manik May 8, 2006 11:44 AM (in response to brian.stansberry)Yes, I was referring to
If the buddy can retrieve state from a persistent store, it isn't requirement to transfer the in-memory copy.
I agree with you about the non-shared case though. The in-memory state could be optional (and probably should be set to false in the BR scenario since the state transferred is backup data after all) -
4. Re: Controlling state transfer behavior with BuddyReplicatio
manik May 22, 2006 8:28 AM (in response to brian.stansberry)Just spotted something when discussing some BR concepts with Bela last week - how would state transfer work if we are using optimistic locking? This is actually irrelevant of whether BR is used.
-
5. Re: Controlling state transfer behavior with BuddyReplicatio
brian.stansberry May 22, 2006 1:58 PM (in response to brian.stansberry)Basically, a RL is acquired on the root node of the region being transferred, and then the node is passed to this method:
private void marshallTransientState(DataNode node, ObjectOutputStream out) throws Exception { Map attrs; NodeData nd; // first handle the current node attrs=node.getData(); if(attrs == null || attrs.size() == 0) nd=new NodeData(node.getFqn()); else nd=new NodeData(node.getFqn(), attrs); out.writeObject(nd); // then visit the children Map children = node.getChildren(); if(children == null) return; for(Iterator it=children.entrySet().iterator(); it.hasNext();) { Map.Entry entry = (Map.Entry) it.next(); marshallTransientState((DataNode) entry.getValue(), out); } }
Whatever nodes are returned by node.getChildren() will be included in the transfer. You just told me workspace nodes will not be returned by that call. So, the state transfer will ignore the workspace, which IMO is correct. The state transfer recipient will get the workspace modifications as part of normal replication when the tx commits. -
6. Re: Controlling state transfer behavior with BuddyReplicatio
manik May 23, 2006 11:18 AM (in response to brian.stansberry)Yes, so far this sounds good, but what about the other end, where state is applied?
Do you explicitly ask for write locks on the nodes, or would you pass up put() calls which will result in a workspace for the state transfer 'transaction'?
The reason I ask is that I wonder how a concurrent put() and state transfer would be handled. -
7. Re: Controlling state transfer behavior with BuddyReplicatio
brian.stansberry May 23, 2006 1:13 PM (in response to brian.stansberry)Not sure I fully understand your question.
On the recipient side, a RL is acquired on the root node into which the state will be integrated (I think this s/b a WL -- IIRC correctly Ben and I discussed this last Sept, but I don't remember why we decided a RL is OK). Then that node's data map and children map are cleared, the data map from the first NodeData in the passed state transfer is integrated, and new Nodes are created and inserted for all subsequent NodeData objects in the passed state transfer.
There is no put() call or transaction involved.
Re: a concurrent put and state transfer, not sure exactly case you are describing:
1) Someone calls put on the cache receiving the state transfer at the same time the state transfer is on progress. This is a mistake in the application, exposing the tree to put() calls before the state transfer is done.
2) Someone calls put() on the sender while the state transfer is in progress. In that case, the workspace node will be created on the sender, will not be included in the state transfer, and will be replicated when the tx that wrapped the put() is completed. -
8. Re: Controlling state transfer behavior with BuddyReplicatio
manik May 24, 2006 5:41 AM (in response to brian.stansberry)Makes sense. Just wanted clarification. I wasn't sure how state was applied to nodes on the recipient end, i.e., if nodes were locked manually or passed up the interceptor chain as method calls.
What you're saying makes sense though, and should be safe for both optimistic and pessimistic locking modes.