Subject: RE: Comments on Partial Locking -01

From: Mehmet Ersue <[email-masked]>
Date: Tue, 11 Dec 2007 20:53:15 +0000 (GMT)

Hi Balazs, Martin, Andy,

I believe the rule in RFC4741 is correct and should be kept if two subsequent locks are done by different sessions.
Let us assume shortly ;-) that the rule wouldn't exist for two subsequent locks done by the same session.

IMHO:
a) A partial lock after a global lock MUST fail.
b) A global lock after a partial lock SHOULD be allowed.
I) If above happens it is the easiest way of implementation (for the managing session and the managed node) if the global lock and partial lock are handled independently.
I.e. the proposal would be that the partial lock survives the global lock and can be freed when the session decides to do so in its sw module hierarchy (whereever in the module the decision is taken). Since it is one session doing it I would assume the locks are done and released based on a FIFO principle.
II) The same behaviour I would also assume in case of an overlapping partial lock.

Martin Bjorklund wrote:
> Sent: Tuesday, December 11, 2007 9:10 PM
> To: [email-masked]
...
> Suppose you write a routine that grabs a lock of /foo/bar/baz, does something and then
> releases the lock.  Later, you might call this routine from code that
> already have /foo/bar locked (or /foo/bar/baz/xxx/yyy).  Thus one can
> argue that the code on the manager will get more complicated if we
> don't allow overlapping locks.
> 
> I will also argue that the code in the agent does not necessarily
> become more complicated with overlapping locks (we have implemented
> overlapping locks actually).  But maybe that wasn't your point.

This is case II) and it seems to be the modular way of implementing a managing session.

Balazs Lengyel wrote:
> Sent: Tuesday, December 11, 2007 6:49 PM
> To: Andy Bierman
... 
> However I don't see this as important, so it is up to Mehmet to fight for it. For the time being I will not add it to the draft.
> Balazs

I wasn't in the discussion when the clausel in RFC 4741 has been finalized.
I believe it would make sense to allow case b).
Nevertheless if there is nobody then me supporting this kind of change then I am willing to accept the decision which has been taken in the WG at that time.

Cheers, 
Mehmet 

> -----Original Message-----
> From: ext Balazs Lengyel [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 6:15 PM
> To: Mehmet Ersue
> Cc: [email-masked]; Martin Bjorklund
> Subject: Re: Comments on Partial Locking -01
> 
> Hello Mehmet,
> We could propose to allow a global lock after a partial lock 
> by the same session, it is even 
> logical in a way.
> 
> However the main NETCONF standard says:
> "      An attempt to lock the configuration MUST fail if an existing
>        session or other entity holds a lock on any portion of the lock
>        target."
> This means we can not allow the global lock. I think what you 
> propose does not violate the 
> spirit of the RFC4741, but it does violate the exact rule in the RFC.
> 
> Also we would have to deal with some tricky cases:
> 1) session A issues partial-lock-A
> 2) session A issues global-lock
> - Should the partial-lock still be kept, or does this automatically remove all partial locks 
> for session-A for the specified datastore? (propose YES)
> - after the successful global lock should it be possible to use a partial lock for the same 
> datastore by the same session ? (propose NO)
> 3) session-A issues global-unlock
> - should the partial locks stay alive ? (propose NO)
> 
> regards Balazs
> 
> Mehmet Ersue wrote:
> > 
> > I wouldn't mind if the full lock does not fail when both of 
> the locks 
> > have been initiated by the same session.
> > Then the question is whether the partial lock should 
> survive which seems 
> > to be useful.
> > 
> > Cheers,
> > Mehmet
> 
> 

      Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail

---

From: "Tomasz Mikołajczyk" <[email-masked]>
Date: Thu, 13 Dec 2007 09:12:32 +0100

> b) A global lock after a partial lock SHOULD be allowed.

I don't agree with the point a). In the case when a session A wants to
lock (partial lock) /foo/bar and /foo/baz, it can execute the global
lock first to protect against the situation, when during partial
locking /foo/bar another session (B) would lock partially /foo/baz. It
means that after the following steps:
1) global lock
2) partial lock of /foo/bar
3) partial lock of /foo/baz
4) global unlock
session A keeps lock on /foo/bar and /foo/baz.

Regards
Tomasz Mikolajczyk

> I) If above happens it is the easiest way of implementation (for the
> managing session and the managed node) if the global lock and partial lock
> are handled independently.
> I.e. the proposal would be that the partial lock survives the global lock
> and can be freed when the session decides to do so in its sw module
> hierarchy (whereever in the module the decision is taken). Since it is one
> session doing it I would assume the locks are done and released based on a
> FIFO principle.
> > However I don't see this as important, so it is up to Mehmet to fight for
> it. For the time being I will not add it to the draft.
> > Balazs
>
> Nevertheless if there is nobody then me supporting this kind of change then
> I am willing to accept the decision which has been taken in the WG at that
> time.
>
> Cheers,
> Mehmet
>
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2007 09:27:44 +0100 (CET)

> session A keeps lock on /foo/bar and /foo/baz.

This particular use case is actually handled in the current draft by
doing a single operation:
   
  partial-lock(/foo/bar, /foo/baz)

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Dec 2007 08:28:34 -0500

>> a) A partial lock after a global lock MUST fail.

Agree.

>> b) A global lock after a partial lock SHOULD be allowed.

Disagree.

A global lock means that I own the store and can do whatever I want
with it.  I can perform my work knowing that no one else will change
the config during the lifetime of my lock.  If you give me a lock
after giving someone else a lock, then we _both_ think we are safe
(which is bad), and I think I can completely change the entire
config (which is either not true or the other guy is busted).  Bad
news all around.  The global lock must trump all partial locks, so
a global lock after a partial lock MUST NOT be allowed.

>locking /foo/bar another session (B) would lock partially /foo/baz.

Is this a real-world use case?  Why would anyone do this?  This
isn't an scenario worth our discussion.  If you get the global lock,
you have no further need of partial locks.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2007 15:01:16 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> (which is bad), 

In both these cases, the discussion is what happens when the same
session performs these requests.

In all cases, as soon as there are any overlaps in locks from
different sessions, the request MUST fail.

This being said, I think it is ok to not allow any overlaps between
the global lock and the partial locks, b/c we do not want to modify
rfc4741.

/martin

---

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Thu, 13 Dec 2007 16:03:18 +0100

> In both these cases, the discussion is what happens when the 
> same session performs these requests.
> 
> This being said, I think it is ok to not allow any overlaps 
> between the global lock and the partial locks, b/c we do not 
> want to modify rfc4741.
> 

A more compelling erason for me is: KISS
i.e. no overlaping locks. Period.

Bert

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2007 16:51:21 +0100 (CET)

Hi,

> i.e. no overlaping locks. Period.

Simple for who?  I would argue that it's not necessarily simpler on
the agent implementation, and maybe even more difficult on the manager
implementation (see my earlier posting in this thread.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Dec 2007 08:34:14 -0800

> implementation (see my earlier posting in this thread.)

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.

Tool implementation is not the key factor.
(That interoperability thing again!)

IMO over-lapping locks are OK if they can be easily implemented
with the same behavior, and the partial-lock monitoring is
complete enough to tell exactly what is locked by each lock-id.

> /martin

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Dec 2007 13:15:10 -0500

>locking /foo/bar another session (B) would lock partially /foo/baz.

And WRT the same session:  I'm not seeing the global/partial lock
overlaps within the same session as something that's worthy of more
words than "DON'T".  The app should know what it's locking, why
it's locking it, and which type of lock it needs.  It shouldn't be
changing it's mind in the middle of the transaction.

>the global lock and the partial locks, b/c we do not want to modify

Cool.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Dec 2007 13:23:16 -0500

>to use a Q of lock-id structs, just a lot more memory.

Amen.

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 ;^), then
my most broken app writers will be tickling code that never gets
tickled.  And the feedback from such app writers is often limited
to "it doesn't work", making debugging more difficult.

Don't put complexity into corner cases.  KISS.

Thanks,
 Phil

P.s.: Not that my code ever has bugs.....

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Dec 2007 22:22:01 +0100 (CET)

> >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...

> (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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 13 Dec 2007 21:53:56 -0500

>http://ops.ietf.org/lists/netconf/netconf.2007/msg00708.html

My concern is less with overlapping partial locks than with
the interaction between global and partial locks.  In your
use case, the modular code should know whether it has already
grabbed the global lock.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Dec 2007 12:37:00 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> the interaction between global and partial locks.

Good!  I think we all agree that we don't want to change rfc4741, and
thus we should not allow any overlaps between partial locks and the
global locks.  A global lock MUST fail even if the same session has a
partial lock and a partial lock MUST fail even if the same session has
the global lock.

/martin