Sacha Labourey wrote:
Hello Bela,
Yes, we need some kind of policy. But I thought about something a
little bit
different. In fact, there is already a way for services that have state to
know about partition merging and plug into it. Instead I thought about a
policy where you can receive events
You are talking about a primary-partition approach. The
literature tells
you to shut down members in a non-primary partitions. It is simple to
implement, all right. But it reduces overall availability of a
distributed system, that's why there are many approaches
beyond primary
David Klimek wrote:
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
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Bela Ban
Sent: mardi, 1. avril 2003 02:31
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Partition merge and service state
merge algorithm
David Klimek wrote:
Hi Sacha,
thank you very much for your comments. Now I
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
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
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
Hi Sacha,
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.
Maybe that's one of the points. As I understand
You can subscribe to merge events if you want to implement the merging
yourself i.e. if you use the clustering framework for your own mbeans.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of David Klimek
Sent: jeudi, 27. mars 2003 12:36
To: [EMAIL
Sacha Labourey wrote:
You can subscribe to merge events if you want to implement the merging
yourself i.e. if you use the clustering framework for your own mbeans.
Hi, thank's for answering. Yes I'm using clustering framwork and
membershipChangedDuringMerge, but I didn't find any correct
Hi, thank's for answering. Yes I'm using clustering framwork and
membershipChangedDuringMerge, but I didn't find any correct
alghorithm
how to choose value for conflicting keys. (e.g. Timestamping)
I hoped that I would find this idea in source code for
DistributedStateService but as I
I'm afraid that this problem is unsolvable and there allways be
situations in cluster, that after partition merge, cluster will be in
inconsistent state and would produce wrong output.
No. Cases:
- DRM: we refresh total view after merging
Agree.
- Http session: sticky sessions = the last
12 matches
Mail list logo
