EHC ❯ DiskStore striping patch introduces concurrency bug related to RandomAccessFile instance access
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
hsingh
-
Reporter: mads1980
-
May 24, 2010
-
0
-
Watchers: 2
-
January 17, 2013
-
May 25, 2010
Attachments
Description
Invoking most methods for RandomAccessFile instances should be synchronized. This was properly handled in previous EhCache versions.
However, since DiskStore striping was introduced (EHC-537), a couple of subtle bugs emerged. Check out the following diff which is the basis for EHC-537:
http://gist.github.com/248153
Search for file.setLength(0); (line 126) and file.close(); (line 141) - access to the RandomAccessFile instance(s) is not synchronized, whereas previously it was. What is now synchronized is access to the RandomAccessFiles array, however this is not the same object lock.
Invoking file.setLength() concurrently can produce unexpected results (see Sun bug 6371642 for one example http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6371642).
Concurrent invocation of file.close() should not cause problems with the current Sun JDK implementation (there’s internal synchronization), however the API is not explicit about this, so it would not hurt synchronizing externally as well, especially considering in this case it’s shutdown code which is not performance-critical.
The solution is simply doing this (setLength() invocation):
synchronized (randomAccessFiles) { for (RandomAccessFile file : this.randomAccessFiles) { synchronized (file) { file.setLength(0); } }
And for close():
synchronized (randomAccessFiles) { for (RandomAccessFile file : this.randomAccessFiles) { synchronized (file) { file.close(); } }
Comments
Manuel Dominguez Sarmiento 2010-05-25
Himadri Singh 2010-06-27
Tweaked patch has been checked in.
DiskStore patch including mods for EHC-721, EHC-722, EHC-723, EHC-725, and EHC-726