On Mon, Sep 21, 2009 at 4:14 PM, Iustin Pop <[email protected]> wrote: > > So, I have yet to see how the non-blocking lock acquire changes, but I would > like to raise some issue that might or might not be solved by that code. > > Basically, we have around four usual ways of acquiring locks: > ① single node or single instance > ② multi-node or multi-instance > ③ set of instances and set of nodes (independent of one another, and rare > except all) > ④ set of instances and their associated nodes > > ① is the only one which, today, can't create locking issues. ② is simple > to fix so that it doesn't create issues (simply abort if not all can be > acquired). But ③ and ④ have issues due to their multi-step approach > (based on locking levels). > > I think that unless we solve the multi-step approach (again, the new > design might solve it but I don't know how), we will still have > problems.
Not if we can rollback all steps, if the second one fails. (so the rollback can also be done on more than one level, rather than on only one). (I think the design hansmi sent last week has this). > Therefore, I think that allowing the locking library to > understand "lock all of this set of nodes and instances", in a single > step, and "lock these instances and their nodes", is a better way to > solve the locking issue than changing lock acquire to nonblocking. This we could solved in the GanetiLockManager level, but it depends how do we want to tie this with the config, because of the "what instance are associated to what nodes?" question. It might be not necessary though. > > If the above is done, then I don't think we need many changes to e.g. a > SharedLock itself. All that is needed is the answer to the question: can > I grab this set of locks (atomically). In order to do this you still need try-locking or timeouts in a shared lock. So some changes are needed anyway (currently only blocking acquire is supported). The timeout gives you an option to try "for a while" without still slowing down more than necessary other operations. Thanks, Guido
