Whirlycache is a configurable in-memory object cache for Java. Whirlycache is open source software, released under the Apache Software License.

Whirlycache is built around several design principles that differ from other cache implementations:

1. Require synchronization as infrequently as possible
2. Do as little as possible in the insertion and retrieval operations
3. Soft limits are acceptable for many applications
4. Disk overflow becomes a bad idea very quickly

Visit the Whirlycache home page

Do you have examples of how to use it with Hibernate ?

Currently, no. However, it ought to be fairly straightforward for someone to implement the interface required by Hibernate in order to get Whirlycache to work with Hibernate.

Do you have examples of how to use it with Hibernate ?

Just take one of the other plug-ins like the one Gavin wrote for Coherence and change it to use this cache's API.

Also, Seth, if you or someone from this project are interested in contributing to JSR-107, drop me an email at cpurdy atsign tangosol dot com.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters

Here is the link :
http://www.hibernate.org/233.html

hi,
 my application is in j2ee iam it stores documents in application the caching concept is applyed to documents
 
documents r storing..if user wants to see the documents

it will ask the 1)document name or

2)Filters ( enter any file name charecter starting s like that)

taking these attributes document list will be shown...

if we open that document that document is getting from server memory (or) database

i have to find that document opened from server(caching) r database directly...


then i have to provide report on this ....

but how i test this functionalty to know when object comes from servermemory r database direclty....

i have downloaded the jcache frame ..like junit that is enough r not r any program i have to write please send me some information documents r url about this concept....

.

In my project, Caching is implemented for Documents Search functionality.

So, Documents should be fetched from Application server rather than Database

Server.

U have any idea to test this caching feature using Junit & cactus frame work

tools or anything else?

developers suggest me to do this

-We are implementing this feature for only Title and Keyword attributes in

the Document Search.


this is a product:

j2ee based ..(completely browser based)

server:jboss 3.2.3 (tomcat 5)

back: oracle 10g

this is information i collected from my project ...

can u please provide me information ..
thanks advance..

How does this compare to JCS? http://jakarta.apache.org/turbine/jcs/JCSandJCACHE.html
This seeme a rather limited. Could it be distributed?

there seems to be a number of Object memory object caching options out there, monitoring, the ability to query, cache-to-disk and back I beleive are some of the features that most have yet this doesn't seem to offer any of that, nor a set of taglibs either which even the more JSP centric OSCache by OpenSymphony
offers http://www.opensymphony.com/oscache/

Sorry I dont see what Whirlycache is offering over these implementations, furthermore, lesser feature laden java object databases seem to offer many of the features of an object caching system.

Has there been any progress on JSR-107?

Marc

Sorry I dont see what Whirlycache is offering over these implementations, furthermore, lesser feature laden java object databases seem to offer many of the features of an object caching system.

Speed. Simplicity.

seth

>Sorry I dont see what Whirlycache is offering over these implementations, furthermore, lesser feature laden java object databases seem to offer many of the features of an object caching system.Has there been any progress on JSR-107?Marc

Well, I have read JSR-107 and I think that both implementations of it and Whirlycache have a place in the world.

In summary, JSR-107 describes a generic object caching service with clustering and disk overflow. In my own testing, disk overflow is a bit of a joke because it starts to be really slow very quickly (of course, this depends on the speed of your disk, among other things!).

Now, some people will obviously need to cache large amounts of data. Whirlycache isn't for them, because we do everything in-memory. And I think that my feeling about this matter specifically is that when you get to the point where you need to do disk overflow, you ought to just use a traditional database and write your cached objects back into that. It will handle the locking concerns for you and will likely provide caching facilities of its own.

Doing a distributed cache is a possibility but no work has been done on this yet. The main concern when you're doing a distributed cache is locking, because the amount of synchronization required across the participating nodes increases with the addition of each new node.

In the meantime, if you want a very fast, configurable in-memory cache, I encourage you to download Whirlycache and ask questions on the list. We will be happy to answer your questions and discuss ideas with anybody.

4. Disk overflow becomes a bad idea very quickly

Why?

I always thought that it was a good idea to overflow objects to local file system if they cannot fit in memory.

--Dmitriy.

4. Disk overflow becomes a bad idea very quickly

Why?I always thought that it was a good idea to overflow objects to local file system if they cannot fit in memory.--Dmitriy.

The primary goals of Whirlycache are to attain the highest speed possible in the simplest manner. Introducing disk overflow (as well as clustering) causes additional complexity (obviously) and results in reduced performance.

That said, you may need disk overflow (in many caching scenarios, useful datasets are likely to fit in memory in their entirety; if they don't, it makes sense to use an appropriate eviction policy so that the objects most likely to be used are available and the rest can be loaded in the normal manner (i.e., poor man's disk overflow)), in which case Whirlycache may not be the best fit.

seth

It's good to see yet another opensource effort towards a better Java caching system. (Some existing caching system has nothing less than a total mess in the internal implementation.)

It would even be nicer if we can see a caching API built upon Java generics, providing type safety at the compliation level.

Keep up the good work hope Whirlycache will evolve well.

I'm obviously missing something here ... if this thing doesnt do eviction or persistence of any form them what exactly does it give me over plain old Hashmap (for example) ?.

Paul C.

I'm obviously missing something here ... if this thing doesnt do eviction or persistence of any form them what exactly does it give me over plain old Hashmap (for example) ?.Paul C.

I can't speak for the details of Whirlycache but how about...
1) Thread Safety
2) Memory Usage (i.e. using a SoftReference to stop the cache taking up all the available memory)

I'm obviously missing something here ... if this thing doesnt do eviction or persistence of any form them what exactly does it give me over plain old Hashmap (for example) ?.Paul C.

I can't speak for the details of Whirlycache but how about...1) Thread Safety2) Memory Usage (i.e. using a SoftReference to stop the cache taking up all the available memory)

plus:<br/>
3) tests for 2GB and 4GB boundaries, and over 4GB data (64 bit environment)<br/>
4) share memory mapped files "out of process" by anything, not just java (e.g. with help of MappedByteBuffer in java and mmap in C) <br/>

I can't speak for the details of Whirlycache but how about...
1) Thread Safety
2) Memory Usage (i.e. using a SoftReference to stop the cache taking up all the available memory)

It is fully thread safe and was written specifically with multithreaded environments in mind.

Your point about using SoftReferences is a good one and something that I have been considering for a while now. If you have specific ideas, I encourage you to join the Whirlycache mailing lists so that you can share your ideas with us because we are interested in hearing from people.

I'm obviously missing something here ... if this thing doesnt do eviction or persistence of any form them what exactly does it give me over plain old Hashmap (for example) ?.Paul C.

They do eviction, but not at retrieval time to keep it fast.
They evict in the background at regular time.
Take time to read the Design part of the home page, it explains pretty what what they do and give some hints on the advantages and limitations of Whirlycache.

Whirlycache *does* offer configurable eviction policies and we have several in the 0.6 release. You just specify which one you want to use in the whirlycache.xml file. Or you can write your own by implementing one simple interface and maybe you can even contribute it back to the Whirlycache project?

Regarding a HashMap, we do offer a synchronized HashMap backend implementation as a benchmark, but it's much slower than, say, the ConcurrentHashMap implementation when running in a multithreaded environment. The reason for this is because all store/retrieve operations need to be synchronized when using a HashMap, whereas a ConcurrentHashMap can do mostly unsynchronized store/retrieve operations which results in much higher throughput.

I believe that there are some benchmark classes in the 0.6 release that will demonstrate this difference to you if you are further interested.

Hi,
JDO technology allows to use a datastore as cache with the following advantages:

- objects can be stored in any data store (RDBMS, ODBMS, File, etc.)
- persistent objects can be shared across multiple JVMs
- you can pin/unpin objects from cache and make many other things to optimize cache usage. Furthermore many implementations allow many own cache features.

Lets' use JDO!

bye,
Luca Garulli
www.OrienTechnologies.com

From the testing that we have done, it appears to be faster than any other Java cache that we have been able to inspect.

Why don't you publish your benchmark. Make sure you include the ORO cache (http://jakarta.apache.org/oro/) and JOCache (http://jocache.sourceforge.net/).

Note that there is a relationship between features and performance; I'm not saying the fastest cache is the best.

I added Whirlycache to the Javapedia:

http://wiki.java.net/bin/view/Javapedia/Cache

If this implementation deserves being added to Javapedia, then maybe you can add my Cache implementation as well? It can be downloaded here.
---
Best regards, Pavel.