Yes, sure. In the meantime, I've added my SFSB proposal to the clustering
todo list.
Thank you for this discussion,
sacha
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of David Klimek
> Sent: lundi, 31. mars 2003 00:07
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Partition merge and service state
> merge algorithm
>
>
> Hi Sacha,
>
> 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
>
-------------------------------------------------------
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
