On Mon, 12 Mar 2001, Sacha Labourey wrote:
> Hello Tom,
>
> > I think that this last point is one which is being lost on some
> > people. It means that there can be no central controller. Everything
> > must work in a completely distributed way. I have tried to describe how
> > this might work. For instance, there can not be a 'master' jndi
> > repository, which is replicated, nor can there be a 'master' transaction
> > manager, message queue... anything. This is why the private/public JNDI
> > tree became necessary, so that some services could retain an identity at
> > each node, while beans are federated across the nodes, and a lookup on
> > them may return an instance at any node.
>
> OK, I see what you mean: difference between a bean and a service i.e.
> between a cluster-view and a node-view.
>
> Consequently, you suggest to have the public tree (cluster-view) being
> replicated at each node and all the private (i.e. node-view) trees, local to
> each node, being federated under the public tree. Right? (or we may as well
> have the public (cluster) tree federated under each private local tree)
Yes, you are correct.
> > > 2nd, this "where-could-i-find-such-a-bean..." mechanism is probably not
> > > strict enough.
> >
> > What do you mean be this? How is it not 'strict' enough?
>
> I meant too lazy => not enough optimized. But I may have missed your point!
Yes, it is possibly that. But the other option is to keep a replicated
index of which PK can be found where (!) This is a clear
memory-performance tradeoff.
> > Having thought this through a little more, what I really meant was that
> > objects in JNDI should be treated differently depending on whether they
> > are services or EJBs. A service should have an identity at each node
> > within the cluster. For a 10-node cluster, there will be 10 transaction
> > managers, which are co-operating to provide distributed
> > transactions. Each one still retains it's own identity. So there is a
> > transaction manager in each 'private' JNDI, which is not visible to the
> > client anyway. Then there are beans, which have to exist as one entity
> > across all the nodes. Do you see what I am saying? There are two
> > different sorts of clustering happening here. One is that of many
> > individuals working independantly to provide a service, the other is one
> > corporate body making up a service. The 'public/private' thing might be a
> > bit confusing, it was just a way of implementing this.
>
> OK, I agree with need such local vs. global representation.
>
> > > > The list of other live nodes would probably be best acheived
> > by a regular
> ...
> > > ...). (in fact, the failure detection mechanism is a basic layer of the
> > > group communication problem)
> > >
> > > What do you think?
> >
> > I like this group communication thingy, except for that everyone I've
> > heard explaining it seems to have advocated having a central controller,
> > which gets messy in the case of the controller failing. I have tried to
> > avoid this.
>
> ?!? the group communication scheme as generally implemented (like
> javagroups) is completely redundant. At a particular moment you have some
> kind of master that sequences the system. But, a completely distributed
> failure detection subsystem will detect its death (or the death of any other
> node). And if the "controler" dies, a distributed election mechanism
> automatically takes place. There no single POF. Have I answered your concern
> or am I (again ;) ) missing your point?
No, that is cool. I just find the concept of having a controller, even a
transitory one, a bit messy. I prefer the 'all are equals' approach,
rather than the 'first among equals'. But that is for purely aesthetic
reasons.
Tom
--
"If you mess with something for long enough it will break."
- Schmidt's law of engineering
