[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on Partial Locking -01
- To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: RE: Comments on Partial Locking -01
- From: Mehmet Ersue <firstname.lastname@example.org>
- Date: Tue, 11 Dec 2007 20:53:15 +0000 (GMT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MyvfCihfmERpNV0oUTxAQmsS0+LGtTTFoYKQkL7mb/XLQM8mrIW7Mbw3s/QvrXcyFcfFatUc6DtQdbhiUuFMwI7EMfdexZgGvpElQ99x+IhKqWC4uak4g5PZnawCEzSDeAVdfX+f6i3E/0A9hXRT2JcsyF3ZqahBT1OwQZvbMpA=;
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.
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@example.com
> 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
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.
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.
> -----Original Message-----
> From: ext Balazs Lengyel [mailto:firstname.lastname@example.org]
> Sent: Tuesday, December 11, 2007 6:15 PM
> To: Mehmet Ersue
> Cc: email@example.com; 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
> 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? Versuchen Sie´s mit dem
neuen Yahoo! Mail.