sure go ahead :)
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Filip Hanik
|Sent: Friday, December 22, 2000 12:32 PM
|To: jBoss Developer
|Subject: [jBoss-Dev] JavaDoc - any objections?
|
|
|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
|>
|
|
|
