• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • lorban
  • Reporter: gabuzo
  • April 27, 2011
  • 1
  • Watchers: 3
  • July 27, 2012
  • April 29, 2011



I found a strangeness when mixing transactional XA mode and disk overflow. When running the following piece of code with bitronix or atomikos, everything is working find and EhCache removes the excess elements from memory as expected.

public void createCache() {
    this.cacheConfiguration = new CacheConfiguration("MyCache", 5000).diskPersistent(false).eternal(true)
    final Configuration config = new Configuration();
    final DiskStoreConfiguration diskStoreConfiguration = new DiskStoreConfiguration();
    this.cacheManager = new CacheManager(config);
    this.cache = new Cache(this.cacheConfiguration);
    for (int i = 0; i < 100; i++) {
        final Integer value = Integer.valueOf(i);
        this.cache.put(new Element(value, value));

If I change {{diskPersistent}} to {{true}} I get the following exception as soon as EhCache tries to move an element to the disk storage:

{noformat}[primaryCache.data] ERROR n.s.e.s.c.f.DiskStorageFactory btm-gtrid=737072696E672D62746D0000012F9296448C00000000 - Disk Write of 0 failed (it will be evicted instead): java.io.NotSerializableException: net.sf.ehcache.transaction.ReadCommittedSoftLockImpl {noformat}

This is _expected_ as switching Ehcache to transactional mode makes it replace the original values of {{Integer}} type by an unserializable {{SoftLock}}:

{noformat}[main] DEBUG n.s.e.t.local.LocalTransactionStore ehcache-txid=0, btm-gtrid=737072696E672D62746D0000012F9296448C00000000 - put: cache [primaryCache] key [0] was not in, soft lock inserted {noformat}

I attached the full projet including the main and the pom.xml.


Ludovic Orban 2011-04-29

Fixed in trunk.

Ludovic Orban 2011-04-29

Please let me know if that fix should be merged to a branch and if yes, into which one.

Fiona OShea 2011-05-02

Please merge to ehcache-2.4.x as well. for a possible 2.4.3 (if we do one)

Sebastian Graca 2011-09-14

The issue is marked as fixed in 2.4.3 but it is still occuring in 2.4.5. I checked the source code for 2.4.3, 2.4.4 and 2.4.5 and it seems that the changes which were applied to the trunk were not merged into releases.

Ludovic Orban 2011-09-14

Merged the code back to the 2.4.x branch.