-
1. Re: Cache with
ben.wang Jan 21, 2004 10:24 AM (in response to goonie)"bwang00" wrote:
"bwang00" wrote:
Hi, Andreas,
Currently we don't support replicate on demand. AFAIK, I don't know any other cache product that does this.
Will use a eviction policy to kick out old items solve your problem in memory size? I am currently implementing the eviction policy (and some other features) on JBossCache. So it should be out in the next release.
Regards,
-Ben -
2. Re: Cache with "lazy" instead of "eager" distribution
goonie Jan 21, 2004 11:07 AM (in response to goonie)"Goonie" wrote:
"Goonie" wrote:
If you need to be scalable, not only processor power is a problem but also memory limits. We can have only 1 GB of RAM on our Web Servers but are expecting a lot more of frequently used persistent objects, lets say 5 GB or so.
If you could distribute on demand between 10 nodes, ideally 5 GB of cache would distribute to 500 MB per node. Of course there would still be duplicated, so maybe you'd fill 700 MB per node or so.
Won't an eviction policy throw away all copies of objects on nodes in parallel?
Regards,
Andreas -
3. Re: Cache with
ben.wang Jan 21, 2004 11:28 AM (in response to goonie)"bwang00" wrote:
"bwang00" wrote:
What you want is a "partitioned" cache then where each node holds only a portion of the whole table. Sorry we don't current support this.
I seem to remember that Tangosol's Coherence has this feature. (Of course, you will then have to pay. :-) You can check them out.
Yes, eviction will be enforced throughout the group.
-Ben -
4. Re: Cache with
cherrydev Feb 12, 2004 12:12 AM (in response to goonie)Currently, http://www.opensymphony.com/ OSCache uses a cache invalidation model, which is a type of 'lazy' distributed cache. Basically, objects are never replicated across the cache automatically. Once they are inside the cache, though, a change in one of the nodes invalidates that object across the cluster. If the other nodes want to access that object again, they will have to fetch it from a data source.
I plan to use this for an upcoming project of mine where I will have an application server and its clients maintain local caches of the application data.
I would love to be able to use TreeCache for this, but since all distributed TreeCaches must have the same contents, this won't work for me since I can't expect the clients to have the same memory capabilities as the application, nor do I expect them to be always working on the same set of data. So, for my purposes, an invalidation cache is ideal. -
5. Re: Cache with
marc.fleury Feb 12, 2004 8:10 AM (in response to goonie)Right,
we need the notion of regions. Do you have cycles to code this? -
6. Re: Cache with
ben.wang Feb 12, 2004 11:07 AM (in response to goonie)It is on the way. I am almost done with eviction policy along with region.
My implementation of region is a collection of nodes where it has different eviction policy. This seems to be what Hibernate and Jcache are gunning for.
However, with this feature, it still doesn't turn it into invalidation model though.
-Ben -
7. Re: Cache with
belaban Feb 16, 2004 2:32 PM (in response to goonie)"Goonie" wrote:
"Goonie" wrote:
"Goonie" wrote:
Hello everyone,
The problem we see with JBossCache is that it always "eager" distributes all objects to each cluster node.
That is not correct. You can configure JBossCache to use asynchronous ('lazy') replication as well.
This would be a memory problem in our case, as each object has to exist on each server. We'd like to replicate each object only on demand ("lazy").
Wait a minute, now you're referring to distribution. Yes, we replicate everything to everyone.
We have partitioning on our todo list, where we only replicate to 1 or 2 (n) backup servers, rather than to everyone. This is not yet done though.
Andreas -
8. Re: Cache with
belaban Feb 16, 2004 2:36 PM (in response to goonie)"cherrydev" wrote:
Currently, http://www.opensymphony.com/ OSCache uses a cache invalidation model, which is a type of 'lazy' distributed cache. Basically, objects are never replicated across the cache automatically. Once they are inside the cache, though, a change in one of the nodes invalidates that object across the cluster. If the other nodes want to access that object again, they will have to fetch it from a data source.
I plan to use this for an upcoming project of mine where I will have an application server and its clients maintain local caches of the application data.
I would love to be able to use TreeCache for this, but since all distributed TreeCaches must have the same contents,
That's not true. TreeCache instances can have different contents, e.g. a new TreeCache may decide *not* to get the shared state.
I'm working on a CacheLoader interface that will be called when fetching/storing an element, so you can implement a backend persistence store to JBossCache, allowing you to do exactly what you want.
.