Hi everyone, 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. Cheers, Ian -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
