Infinispan equivalent to ehcache's copyOnRead and copyOnWrite

I am planning to implement a cache solution into an existing web app. Nothing complicated: basically a concurrent map that supports overflowing to disk and automatic eviction. Clustering the cache could be requirement in the future, but not now.

I like ehcache's copyOnRead and copyOnWrite features, because it means that I don't have to manually clone things before modifying something I take out of the cache. Now I have started to look at Infinispan, but I have not found anything equivalent there. Does it exist?

I.e., the following unit tests should pass:

@Test
public void testCopyOnWrite() {
    Date date = new Date(0);
    cache.put(0, date);
    date.setTime(1000);
    date = cache.get(0);
    assertEquals(0, date.getTime());
}

@Test
public开发者_开发技巧 void testCopyOnRead() {
    Date date = new Date(0);
    cache.put(0, date);
    assertNotSame(cache.get(0), cache.get(0));
}

Infinispan does support copyOnRead/copyOnWrite, albeit the actual format isn't pluggable. The configuration element is lazyDeserialization in Infinispan 4.x and storeAsBinary in Infinispan 5.x. Objects are serialized using the pluggable Marshaller framework, which is used for all forms of marshalling including for RPC calls over a network and storage to disk.

According to a JBoss developer, Infinispan does not yet support such feature. You should log a request for enhancement in the Infinispan issue tracker, so that others may vote on it (I will).

That being said, if you need this feature now, a workaround would be to extend AbstractDelegatingCache, and override the get and put methods to add this functionality. You could use your own copy strategy or look at how EHCache did it for inspiration.

Also, you may consider the Infinispan forum if you have further questions, since you will have more views from the Infinispan community.

I believe storeAsBinary only takes effect when objects need to be serialized which means when a put operation is called, the owner is not the current node.

This also means the testcases in the question could pass if the owner of key 0 is not the current node, but it would still fail if it's a single node environment.