Re: Yet another optimistic locking question

From: Gili (cowwo..bs.darktech.org)
Date: Thu Sep 01 2005 - 11:12:29 EDT

  • Next message: Mike Kienenberger: "Re: Yet another optimistic locking question"

            And I forgot to mention, in step 3 I assume we look at the return value
    from the DB and if we expected 1 change and got 0 this means we detect
    that our DB representation was out of date and we throw an exception,
    correct?

    Gili

    Mike Kienenberger wrote:
    > Yeah, it's basically an atomic db operation that says UPDATE set
    > values WHERE all fields marked for optimistic locking haven't changed
    > values from the last time we read them.
    >
    > On 9/1/05, Gili <cowwo..bs.darktech.org> wrote:
    >
    >> Oh my. It all makes so much more sense now... So if I understand it
    >>correctly,
    >>
    >>1) We store the perceived DB value somewhere
    >>2) We store the cached (maybe modified) value elsewhere
    >>3) When a commit occurs, we compare the objects in 1 and 2, then issue a
    >>UPDATE only for fields which have changed.
    >>
    >> Cool :) This also sounds quite efficient to me.
    >>
    >>Thank you,
    >>Gili
    >>
    >>Gentry, Michael (Contractor) wrote:
    >>
    >>>Optimistic locking never locks the row in the database (it is
    >>>optimistic). Read:
    >>>
    >>>http://www.objectstyle.org/confluence/display/CAY/Optimistic+Locking+Exp
    >>>lained
    >>>
    >>>It explains how Cayenne can ensure that no changes occurred between the
    >>>SELECT and UPDATE phase. If you still have questions I'll try to answer
    >>>them.
    >>>
    >>>Thanks,
    >>>
    >>>/dev/mrg
    >>>
    >>>
    >>>-----Original Message-----
    >>>From: Gili [mailto:cowwo..bs.darktech.org]
    >>>Sent: Thursday, September 01, 2005 12:06 AM
    >>>To: cayenne-use..bjectstyle.org
    >>>Subject: Yet another optimistic locking question
    >>>
    >>>
    >>>
    >>> A question about how optimistic locking is currently
    >>>implemented. Do we
    >>>implement it like this?
    >>>
    >>>1) Lock row
    >>>2) Read row
    >>>3) Compare read row to DataObject version of row
    >>>4) If values mismatch, unlock the row and throw an exception
    >>>5) If values match, continue with update and unlock row
    >>>
    >>> or do we not lock the database at all? If we don't lock it at
    >>>all, how
    >>>can we ensure that no changes occur after step 3 but before step 5?
    >>>
    >>>Thank you,
    >>>Gili
    >>
    >>--
    >>http://www.desktopbeautifier.com/
    >>
    >
    >

    -- 
    http://www.desktopbeautifier.com/
    



    This archive was generated by hypermail 2.0.0 : Thu Sep 01 2005 - 11:12:30 EDT