> 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
