[rfc][icedtea-web] CacheEntry Locking Fix

[Jiri Vanek]

On 08/05/2014 09:08 PM, Jie Kang wrote:
> Hello,
>
> I discovered that the CacheEntry locking system currently does not work as expected. Calls to lock() or unlock() have no real purpose as they do not prevent the properties file from being read or written to. The patch addresses this by preventing writes from the CacheEntry unless one has acquired a lock on the properties file.
>
> There are also two new tests that demonstrate the issue.
>
> The first test 'verifyLockCannotBeUnlocked' tests whether or not CacheEntries can unlock each other's lock. Prior to this patch, if CacheEntry A 'lock's the properties file, CacheEntry B could call 'unlock' and release the lock for entry A. This is no longer possible.
>
> The second test 'verifyLockPreventsWrite' tests whether or not another CacheEntry can write to the properties file while some other entry has the lock. Prior to this patch, if CacheEntry A 'lock's the properties file, CacheEntry B could still read and write from/to the same file. This is no longer possible.
>
>
>
> One issue this does not address is that the :: public void function store() :: in PropertiesFile.java can still be called without a lock. This has not been refactored as of yet due to CacheLRUWrapper.java's use of store() without the need of locking (I think). So it is still up to the developer to make sure he/she writes code that makes use of the locking system when dealing with PropertiesFile.java directly. The patch does make sure developers cannot screw up when dealing with CacheEntry.java.
>
>
> Regards,
>


uff... Does this issue have some real consequences?


J.