Optimistically Pessimistic Locking



  • Our user-representative thinks he knows how to design software and so frequently throws in some buzzwords in his app requirements. Today it's locking.

    We were told to use optimistic locking when getting/putting objects from/to our database. It seemed a reasonable approach so we did it his way (we're only allowed to object when something is completely undoable and then we still need to take THEIR solution, we are not allowed to engineer our own).

    Then the users added different types of transactions:

    a) modify all the attributes of a single object spanning numerous subobjects

    b) modify one attribute of hundreds of business objects of a certain business division.

    So some user would load the huge entity, work on it for an hour and go to save it only to find that some other user had done one of those global update-just-this-field mass updates, which would render the first users work unsavable. Note: there are only 10 users, all of whom sit next to each other in the same room.

    Their solution? Make everything full pessimistic locking. But that will prevent the global updates from ever running because *something* will always be locked. Well, then only make it pessimistic when necessary.

    Um, could you please define that? Yeah, make it pessimistic only if someone else will need the data. Wait, how are we supposed to know that at some point in the future some user will need to modify this specific record?

    And around we go...

     



  • Best I can come up with: Make the "take locks" step of jobs serial, but the jobs themselves can still be parallel.

    Serial part:
    Try to take all locks, get added to lock's queue if someone else already has it (non-blocking)

    Parallel part:
    Wait on all locks
    Do stuff
    Unlock



  • Sounds like your data model is incorrect.... But assuming you cannot change that you're going to have to use pessimistic locking.  Then any records which are locked record in a "pending" table.  When the record frees up, apply the change.



  • See, you remind me of a database-half-empty kind of guy...


  • Considered Harmful

    You could provide a "check out, check in" option for pessimistic locking when needed.

    Alternatively, maybe you could do locking on a more granular level. For example, accept an update from user a to fields 1, 2, and 3, even if user b has updated fields 4, 5, and 6 in the interim. Basically, just check the specific fields being modified. This might require a checkbox or something next to each field saying "yes, I'm modifying/locking this one."



  • You guys are thinking like software engineers - keyword: thinking.

    Both users insist on having 100% right-of-way, with no delays in processing, and each should supercede the other's changes. We suggested that this was the "no locking at all" concept which they refuse to allow.

    The problem is not a technical one at all. It's along the lines of whose changes should supercede whose; e.g.: I started changing this an hour ago. Yes, but even though I started after you, I *committed* first, so screw you and your little changes too *cackle* *cackle*

    Neither user is willing to budge. I wrote an email detailing the problem and different-options-to-solve (with dis/advantages of each) to the common boss and asked him to make a call. He'll make a decision and then it's not on us to deal with idiots; we just need to build it with whatever model he selects.

     



  • @snoofle said:

    He'll make a decision

    Or he'll say: you're the consultant, we pay you a fortune, so tell us what to do. Then, if my users complain, we can always blame you.

    Then again, you might see that coming a mile away and dodge it like a pro.



  • @b-redeker said:

    @snoofle said:

    He'll make a decision

    Or he'll say: you're the consultant, we pay you a fortune, so tell us what to do. Then, if my users complain, we can always blame you.

    Then again, you might see that coming a mile away and dodge it like a pro.

    In the email, I gave 4 choices in descending order of desirability. I even put in a graph (pointless to all but a PHB) to illustrate it. My recommendation was specific and clear, but I always like to give less likely alternatives in order to make my recommendation look more palatable. It's stupid, but if you don't ask for their opinions, managers like to manage. If you ask their opinion and draw easy-to-understand pictures to lead them to your way of thinking, they (usually) decide what you want and then leave you alone because they solved the problem.

    They forced me to learn french in high school, but as an adult I chose to learn to speak corporate-manager - much more useful in real life.

     

     



  • What is the best way to learn to speak corporate-manager, if you exclude dealing with them because nobody really wants that.



  • @TheMugs said:

    What is the best way to learn to speak corporate-manager, if you exclude dealing with them because nobody really wants that.

    It's not that bad. They may have a reputation for being a bit smelly and rude, and prefer to speak their own language even they actually understand English, and their food may not be all that obvious at first, but I can assure you that their women are not nearly as hairy as they're made out to be.



  • @snoofle said:

    You guys are thinking like software engineers - keyword: thinking.

    Both users insist on having 100% right-of-way, with no delays in processing, and each should supercede the other's changes. We suggested that this was the "no locking at all" concept which they refuse to allow.

    The problem is not a technical one at all. It's along the lines of whose changes should supercede whose; e.g.: I started changing this an hour ago. Yes, but even though I started after you, I *committed* first, so screw you and your little changes too *cackle* *cackle*

    Neither user is willing to budge.

    OK, here's how you do it: advisory locking.  Whenever there's a clash between two edits, you pop up a dialog box on each user's workstation, with only one option: accept the other user's changes.  Then the two users have to fight each other and the winner can go and click OK on the loser's terminal, which also makes the "accept other user's changes" dialog disappear from their workstation.



  • @DaveK said:

    @snoofle said:

    You guys are thinking like software engineers - keyword: thinking.

    Both users insist on having 100% right-of-way, with no delays in processing, and each should supercede the other's changes. We suggested that this was the "no locking at all" concept which they refuse to allow.

    The problem is not a technical one at all. It's along the lines of whose changes should supercede whose; e.g.: I started changing this an hour ago. Yes, but even though I started after you, I *committed* first, so screw you and your little changes too *cackle* *cackle*

    Neither user is willing to budge.

    OK, here's how you do it: advisory locking.  Whenever there's a clash between two edits, you pop up a dialog box on each user's workstation, with only one option: accept the other user's changes.  Then the two users have to fight each other and the winner can go and click OK on the loser's terminal, which also makes the "accept other user's changes" dialog disappear from their workstation.

    Is that advisory locking or adversary locking?



  • @DaveK said:

    OK, here's how you do it: advisory locking.  Whenever there's a clash between two edits, you pop up a dialog box on each user's workstation, with only one option: accept the other user's changes.  Then the two users have to fight each other and the winner can go and click OK on the loser's terminal, which also makes the "accept other user's changes" dialog disappear from their workstation.

     

    Include a link to the "Irish Code of Honour", of, if they are of some little value, the "Marquess of Queensbury Rules".



  • @DaveK said:

    Whenever there's a clash between two edits, you pop up a dialog box on each user's workstation, with only one option: accept the other user's changes.  Then the two users have to fight each other and the winner can go and click OK on the loser's terminal, which also makes the "accept other user's changes" dialog disappear from their workstation.
    Ah, a man after my own heart.



  • @DaveK said:

    OK, here's how you do it: advisory locking.
     

    I like the way you think.



  • @aihtdikh said:

    @DaveK said:

    @snoofle said:

    You guys are thinking like software engineers - keyword: thinking.

    Both users insist on having 100% right-of-way, with no delays in processing, and each should supercede the other's changes. We suggested that this was the "no locking at all" concept which they refuse to allow.

    The problem is not a technical one at all. It's along the lines of whose changes should supercede whose; e.g.: I started changing this an hour ago. Yes, but even though I started after you, I *committed* first, so screw you and your little changes too *cackle* *cackle*

    Neither user is willing to budge.

    OK, here's how you do it: advisory locking.  Whenever there's a clash between two edits, you pop up a dialog box on each user's workstation, with only one option: accept the other user's changes.  Then the two users have to fight each other and the winner can go and click OK on the loser's terminal, which also makes the "accept other user's changes" dialog disappear from their workstation.

    Is that advisory locking or adversary locking?

    The best bit of all is that there's only one way it can ever deadlock, and when that happens you won't be receiving any support calls about it.... ;-)

     



  • @DaveK said:

    The best bit of all is that there's only one way it can ever deadlock
     

    I see what you did there.



  • @DaveK said:

    @aihtdikh said:

    Is that advisory locking or adversary locking?

    The best bit of all is that there's only one way it can ever deadlock, and when that happens you won't be receiving any support calls about it.... ;-)

    Headlock (TM). It puts the "e" in "eVolution".



  • @robbak said:

    the "Marquess of Queensbury Rules".


    I assume you mean the "Marquis of Queensberry Rules"? Or did you mean the rules for female boxing or something? :)



  • @b-redeker said:

    @DaveK said:

    @aihtdikh said:

    Is that advisory locking or adversary locking?

    The best bit of all is that there's only one way it can ever deadlock, and when that happens you won't be receiving any support calls about it.... ;-)

    Headlock (TM). It puts the "e" in "eVolution".

    It puts the evil in evolution!

     



  • @Cad Delworth said:

    @robbak said:

    the "Marquess of Queensbury Rules".

    I assume you mean the "Marquis of Queensberry Rules"? Or did you mean the rules for female boxing or something? :)
     

    Marquess is a male title, the English equivalent of the French marquis. The female version is marchioness or marquise.

    Queensberry's title was Marquess.



  • If I can actually say something nice about MUMPS, I like the locking structure it has.  Rather than just getting a lock on a particular value, you get a lock that is a node in a hierarchy; getting this prevents anyone else from obtaining any lock that is a direct parent or descendant of the locked node.

    So e.g. if you've got customer #12345 and you want to edit their address, you can get a lock on (12345,"Address").  Someone else could have a lock on (12345,"Shopping Cart").  Now, if someone wants to lock all of record 12345, they can just lock (12345) - which will queue until the other locks are released, and by being in the queue, it will force any other locks on 12345 to queue as well.

    Of course if you're evil you could just try to get a lock on the root node of the whole hierarchy and grind everything to a halt.



  • @Cat said:

    If I can actually say something nice about MUMPS, I like the locking structure it has.  Rather than just getting a lock on a particular value, you get a lock that is a node in a hierarchy; getting this prevents anyone else from obtaining any lock that is a direct parent or descendant of the locked node.

    So e.g. if you've got customer #12345 and you want to edit their address, you can get a lock on (12345,"Address").  Someone else could have a lock on (12345,"Shopping Cart").  Now, if someone wants to lock all of record 12345, they can just lock (12345) - which will queue until the other locks are released, and by being in the queue, it will force any other locks on 12345 to queue as well.

    Of course if you're evil you could just try to get a lock on the root node of the whole hierarchy and grind everything to a halt.


    That't the way all Hierarchical databases work. You may be "too young" to remember, but back in the day there was quite the fight between hierarchical, network, and relational database systems. Relational won...



  • @Auction_God said:

    That't the way all Hierarchical databases work. You may be "too young" to remember, but back in the day there was quite the fight between hierarchical, network, and relational database systems. Relational won...
     

    I dunno about 'won', nonrelational databases are seeing a resurgence in popularity (the whole NoSQL movement).



  • @Cat said:

    @Auction_God said:

    That't the way all Hierarchical databases work. You may be "too young" to remember, but back in the day there was quite the fight between hierarchical, network, and relational database systems. Relational won...
     

    I dunno about 'won', nonrelational databases are seeing a resurgence in popularity (the whole NoSQL movement).

    Yeah, but the fact that there has to be a "movement" at all (plus the fact that the movement is only defined with "we're not SQL!") kind of demonstrates how thoroughly relational databases won the first time.



  • I agree with the guy who said the data model is wrong.  This should not be a problem.  If you're having to update a single field from a host of records, maybe that field needs to hold a foreign key instead of a value.  Same issue for child objects/records.


Log in to reply