See below On Sun, Apr 3, 2011 at 8:32 PM, Pascal Rapicault <[email protected]>wrote:
> 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? > The lock is relinquished, however, this doesn't remove the .lock file. This is how OSGi locking (or any file locking) works. You can't remove the lock as other processes may be waiting on it. > 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) > Yep, I've looked at this and we have a single method (canLock()) that we can use as stop gap measure. The question is do we enable or disable it by default (we still have a bit of time to decide). cheers, ian > > On 2011-04-03, at 10:09 PM, Ian Bull wrote: > > 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 > > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > -- 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
