Opened 12 years ago
Last modified 7 years ago
#169 new task
icedtea-web: Fix file locking
Reported by: | dmik | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Next |
Component: | icedtea-web | Version: | 1.6.0-b24 GA2 |
Severity: | medium | Keywords: | |
Cc: |
Description
The Java plugin uses java.nio.channels.FileChannel.lock() to serialize access to property files (used mostly for storing cache data) between several plugin instances (represented by separate processes) to make sure the file update operation is atomic in that context.
However, the behavior of locks differs between platforms. In particular, on Windows and on OS/2 the file lock is strictly bound to the file handle. This means that if you open the locked file again and get a new handle for it, the new handle will not inherit the lock and accessing the file through this new handle may fail if the lock condition is violated -- even if the second open happens in the same process.
Since the plugin code uses different handles to lock the property files and to read/write to them, this causes permanent lock violations and prevents these files from being properly updated on OS/2. I guess that on Linux file locks are not bound to file descriptors but rather to the file name and that's why it works. (Windows is not a question here since the plugin is not made to be used on Windows where Oracle provides its own binary distributions).
This needs to be addressed and fixed.
Change History (4)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Milestone: | Next → GA4 |
---|
comment:3 by , 12 years ago
Component: | general → icedtea-web |
---|
comment:4 by , 7 years ago
couldn't the new file locking in libcx help here? I have the feeling it would.
The existing file locking scheme has been disabled in r396.
A proper solution for Windows and OS/2 platforms is to make sure the property files are open for the duration of the property store/load operation and use the same handle bot for locking and for accessing the file. This requires a bit of changes in the source file and hence was postponed.