further thoughts at bottom....
Jules Gosnell wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Well, you guys let me know if I can help you in any way.
Keep on talking ;-)
Okay. I will ask you a question then. What are you doing as far caching
entity beans?
In terms or replication or some form of distributed invalidation, I'm
not aware that this has been discussed yet.
This is another one for the forthcoming doc - briefly :
If you cluster an entity bean on two nodes naively, you lose many of
the benefits of caching. This is because neither node, at the
beginning of a transaction, knows whether the other node has changed
the beans contents since it was last loaded into cache, so the cache
must be assumed invalid. Thus, you find yourself going to the db much
more frequently than you would like, and the number of trips increases
linearly with the number of clients - i.e. you are no longer scalable.
If you can arrange for the cache on one node to notify the cache on
other nodes, whenever an entity is changed, then the other caches can
optimise their actions, so that rather assuming that all beans are
invalid, they can pinpoint the ones that actually are invalid and only
reload those.
You could go one step further and send, not an invalidation, but a
replication message. This would contain the Entity's new value and
head off any reloading from the DB at all....
All of this needs to be properly integrated with e.g. transactions,
locking etc...
Perhaps Totem might be useful here ?
ActiveSpace (in incubator) may already have support for this sort of thing ?
If you had a working clustered cache with a cache loader pointing at the
entity...
Jules
Jules
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
