> Disagree.
>
> Consider following:
>
> 1. Cluster running banking application with SFSB's
Ok.
> 2. Cluster is split into two groups
ok
> 3. Each group continues concurently previous computation
You mean: you may have work in progress for a given set of SFSB on each node
(each node being on a given network partition)
> 4. Second group finishes computation and changes SFSB state
> and produces
> output (assigns money to account)
=> go to the DB => no network partition wrt database access. OK.
> 5. First group still doesn't finish its computation
Ok.
> 6. Partition merge occurs
Ok.
> 7. SFBS state on nodes of second group is rewriten by state of first
> unfished group
No. Here, you make the assumption that you can have CONCURRENT access to the
SAME SFSB which is not allowed per spec. 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.
> 8. Cluster finishes computation again and changes SFBS state and
> produces output (assigns AGAIN money to account)
>
> So we get as I belive incorrect and dangerous cluster behavior.
Do we agree now?
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
