Anyone using Jbosscache as write-back cache?

[gagangoel]

As far as I have read (I am new to Jbosscache :-)..), it seems that Jbosscache has been written with write-through policy in mind(i.e. on write, changes are also transfered to persistent store through cacheloader).

The application that we are running has significantly large number of writes than reads, and one motivation for using cache was to reduce the number of database hits by preventing a write to database each time cache entry is modified.

So a better solution in our case would be to use write-back policy. i.e. on writes, write only to the cache. And on eviction, data is saved back to database. But now the problem is that most recent data might not be available on database. So on read operation, if the node is not available in cache then the cacheloader should have some algorithm to check if some group member-server is holding the recent data, and if they do, then get the data from them. There are also some other non-trivial issues which arises in write-back policy.

I was wondering if write-back policy is already implemented in jboss-cache which has skipped my attention, or if someone else has implented or tried to implent this.

Thanks

[ben.wang]

This is the overflowing (or passivation) policy. we have that in roadmap (and currently have someone looking at it now) but not yet implemented.

-Ben

[belaban]

You're talking about 3 different issues, which are all on the roadmap:

1: Activation&passivation: we are working on this
2: Write-behind caching. This is also on the roadmap. This will be in the form of a CacheLoader which fronts other CacheLoaders, and buffers all writes, then writes then asynchronously
3: Delegating (clustered) CacheLoader: if an element is not in the cache, we'll try to find it within the cluster.

[gagangoel]

thanks for your response.

I saw that these features are included in version 1.3. Can you tell what is the tentative release date of this version.

thanks
Gagan

[belaban]

1.3 is a catch-all release, we will most certainly push features out into 1.3.1 or 1.4.
But I'd say the 3 features I mentioned above should make it into 1.3.
1.2.4 should be released by end of August.
With 1.3, we will schedule a dev release 1, maybe 2 But I want to release 1.3 before the end of the year.