|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.
It would become "pinned entities" in the sense that once you assign an
entity to a node it stays there. There were some discussions made by
Inprise chief alien recently that argued against this...
can someone refresh our memory (had to do with too much traffic for complex
apps)
|
|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.
The price of "distributed synchronization seems to be deemed less than the
price of "pinned" entities... gee I don't know...
what is theoretical and what is "real" usage?
|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 it coming, also there is some developer documentation coming together
Vladimir you there yet?
marc
|
|keep me posted where this is going,
|Happy Holidays
|Filip
|
|
|
