Hi,
I'm slowly going through the code for jboss, it will take me some time.
Since I am going through the code and trying to understand it, I might as
well JavaDoc missing pieces.
Would this be ok with the respective authors. I will notify the mailing list
about any javadoc changes I make to the source code
cool with everyone?
Filip

----- Original Message -----
From: "Filip Hanik" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>
Sent: Friday, December 22, 2000 10:31 AM
Subject: Re: [jBoss-Dev] using Jini for clustering


>
>
>
> > for stateless there is no state, for stateful there is one point of
access
> > and we can passivate to reconstruct in nodes, and for entity if we don't
> > want to pin the state then there are more gymnastics with the DB... not
> > pinning an entity means relying on the DB at some point == not good.
> >
> >
> > marc
>
> probably a good idea to separate out read-only entity beans versus
> read-write entities?
> but you are right, if we don't pin the state, then there is more stuff
done
> with the DB, also, what if the EJB is relaying on some other persistent
> store with a lot worse performance than, let's say, Oracle. The bean
> developer would not like the container to go back and forth between the
> persistence and the server.
> could a read only entity be treated as a stateful session bean in terms of
> cluster logic?
> the only difference would be that you could have more than one client
> hanging on (holding a reference) to it.
>
> I've been thinking about how Gemstone implemented their "replication/fail
> over".
> They replicated out an object to several VMs, but they all tied back into
> the source object in their object database.
> Once the object entered into a write transaction, the object would lock
the
> root object, so that the other replicas couldn't write (interfer) with the
> write transaction. This also guaranteed read consistency for the other
> objects while the transaction was taking place. Once the transaction was
> committed the all the replicas were updated in the timely fashion.
> Of course, at this time (1998) Gemstone had a single point of failure, it
> was called the "Stone" and all the VMs relied on this process to be in
> place.
>
> I still have to catch up with what is going on with the JBoss source,
before
> I can make any rational suggestions to the implementation.
>
> keep me posted where this is going,
> Happy Holidays
> Filip
>


Reply via email to