> 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
