|I'll be travelling. I won't be able to attend the call.|
I think Tom will also not be able to attend as he is at the OSGi f2f.
A quick question, why isn't the read lock cleared away at the end of the read?
Also IIRC you have some new personal projects coming out soon, so it may make sense to put in a place a stop gap measure that allows to disable this new locking support in case we did not had the time to completely polish it off (read do the VM arg thing)
On 2011-04-03, at 10:09 PM, Ian Bull wrote:
As many of you know I've implemented artifact repository locking in p2. This is an important first step if we really want multiple processes to concurrently access the same artifact repository (in bundle pooling for example). There have been a few small issues that I've been fixing (ugly printouts for examples). There is also an unfortunate side effect from this approach -- the retention of lock files, even after eclipse terminates. Since we are using read locks, a simple provisioning operation will create a lock file if the operation was performed against a local repository. Some users perform their provisioning operations as 'root' which means that a lock file will be created, and standard users cannot clean them up.
I would like to spend some time tomorrow (at the Equinox / p2 call) to discuss this issue. I've been exploring a few alternatives:
1. Remove the read locks (only leave the write locks). This will likely lead to problems if one process attempts to read an artifact repository while another process is currently writing it.
2. Release locking as provisioning in 3.7 / 4.1 -- i.e. disabled by default, and provide a VM arg to enable it.
3. Leave things the way they are (if you really don't want read locks you can set your repository as readonly).
4. Don't use .lock files, but instead use the artifacts.jar as the lock file. This seems like the best solution and I've spent some time this weekend prototyping it. There are a few challenges with this approach that may be show stoppers (we allow users to change the 'shape' of the repository -- from .jar to .xml. This means that the .lock file will suddenly change; how do we deal with this? Also, what comes first, the repository or the lock?).
5. Remove the locking all together (i.e. roll back the change). I'm
obviously not in favor of this solution, but it is a possibility.
If anyone has thoughts / ideas on artifact locking please stop by the equinox call tomorrow.
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
p2-dev mailing list