thank you very much for your comments. Now I believe I have quite clean picture of partition merge issues.
Maybe the conditions and limitations you mentioned should be added to documentation as they are not obvious and there can be a lot of people living, as I did before, in paradise, where all the mess with state merging, is handled by clustering framework.
Greet's David
Sacha Labourey wrote:
Maybe that's one of the points. As I understand partion "split" each groups things that all nodes in other group are down, but they are not so there is not chance how to avoid concurrent access.
Yes. But solutions may be found, such as using a central DB as a way to decide who is up/down.
Anyway the same problem can occur in DistributedState service from JBoss Clustering framework, where no such limitaton is explicitly given by spec.
Yes, this must be added for generic use. But let's finish our SFSB discussion first as it is a little bit different.
Furthermore, even in the strange
scenario you describe (concurrent access to a same SFSB),
the merge would
not update the remote nodes until a new SFSB operation
occurs i.e. with
SFSB, we replicate only when we modify a SFSB, not when a
merge occurs.
That's even worst.
Suppose after partition merge group 1. has SFSB in state A and group 2. has SFSB in state B.
We DON'T merge state for SFSB.
First, as I belive, after partition merge you can get inconstent behavior. If you use SFSB replica from node in group 1. you get state A if you read SFSB replica from node in group 2. you get state B.
Yes, but remember that the choice of the node is done in the CLIENT proxy which will ALWAYS use the same target as long as it is available.
Second, when SFSB modify to state C occurs, one node rewrites state B and A on all other nodes. So group of nodes went through states A-C and group through states A-B-C with all consequences.
Yes, the solution is in the fact that we don't merge the state and we always go to the same node. The only situation where something bad could occur is: - client A use node 1 - partition is split - client A continue using node 1 - node 1 cannot transmit its updates to node 2 because of the net partition - client can suddently no more reach node1 - it failover to node 2 but node 2 has the old state!
If this is a problem for you, we could imagine to send piggy-back to the client proxy, the state version id. If, when we failover, we have a lower value, we could throw an exception.
Maybe I could try to prepare some testcase demonstrating problem.
Sorry if am I missing something, but I still strongly believe, that merging partions is very dangerous and can put cluster in
Yes, which is why we don't merge.
inconsistent state. It seems to me, that it is as complicated as to try "merge" the state of two computers (processors, memory, I/O devices) after they run separateted for a while.
Yes, you are right, it is application specific, there is no generic way to take such a decision.
Cheers,
Sacha
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
-- http://www.sweb.cz/david.klimek
------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
