Cache with "lazy" instead of "eager" distribution

[goonie]

"Goonie" wrote:

"Goonie" wrote:
Hello everyone,

we are planning a large business application with just a few database tables but many rows in the tables. For performance and fail-safeness we will be using a cluster of servers. We are thinking about using Hibernate and JBossCache.

The problem we see with JBossCache is that it always "eager" distributes all objects to each cluster node. 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").

Can JBossCache be easily customized to this behaviour or is there any other Cache solution for this (that fits with Hibernate and maybe JBoss CMP)?

Regards,

Andreas

[ben.wang]

"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

[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

[ben.wang]

"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

[cherrydev]

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.

[marc.fleury]

Right,

we need the notion of regions. Do you have cycles to code this?

[ben.wang]

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

[belaban]

"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

[belaban]

"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.


.