Hi Martin, Phil,
Martin Bjorklund wrote:
> Phil Shafer <phil@juniper.net> wrote:
> > Andy Bierman writes:
> > >IMO, it is simpler for the agent implementer to tag each
> > >locked node with just one lock-id, but is not much harder
> > >to use a Q of lock-id structs, just a lot more memory.
> ^^^^^^^^^^^^^^^^^
>
> Well... yes if there will be a lot of partial locks. But an
> implementation can of course always return resource-denied if
> necessary. Note that an
application that puts a partial lock on every
> leaf in the entire config datastore also use lots of memory...
>
>
> > Another point of view: when you put complexity in places it will
> > never be exercised, the likelihood of bugs increases. So if the
> > amount of code I have to write to handle a broken app is large
> > (assuming apps with overlapping locks are likely broken ;^),
>
> I mentioned a possible use case in
> http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html>
> Maybe you'd call it broken.
>
> /martin
If you implement a huge amount of modular code for configuration management
(which is probably split into different threads)
you don't want to keep a tally of already executed partial locks
nor do you want
to lock strongly sequentially and step by step.
IMO it is indeed more complicated to handle the situation when overlapping locks are not allowed.
As long as the partial locks are executed from the same session and simple rules are followed (e.g. last lock-first release)
you are on the safe side and have the flexibility for the implementation of a modular manager.
Mehmet