Open Stack

On 07/30/2014 02:29 PM, Kevin Benton wrote:
> Yes, we are talking about the same thing. I think the term 'optimistic
> locking' comes from what happens during the sql transaction. The sql
> engine converts a read (the WHERE clause) and update (the UPDATE clause)
> operations into an atomic operation.
> The atomic guarantee requires an internal lock in the database on the
> record after it is found by the WHERE clause but before the UPDATE is
> completed to prevent a simultaneous query with the same WHERE clause
> from updating the record at the same time.
> So the lock (or some serialization strategy) is still there, but it's
> just buried deep in the SQL engine internals where they belong. :-)

Gah, let us resolve to agree then :) Yes, a mutex is held on a 
section/page of the write-ahead transaction log for a moment in order to 
guarantee durability, so sure, yes, there is a lock held.

Just not on the record itself :P

-jay

> On Jul 30, 2014 2:00 PM, "Jay Pipes" <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
>     On 07/30/2014 12:21 PM, Kevin Benton wrote:
>
>         Maybe I misunderstood your approach then.
>
>         I though you were suggesting where a node performs an "UPDATE record
>         WHERE record = last_state_node_saw" query and then checks the
>         number of
>         affected rows. That's optimistic locking by every definition
>         I've heard
>         of it. It matches the following statement from the wiki article you
>         linked to as well:
>
>         "The latter situation (optimistic locking) is only appropriate when
>         there is less chance of someone needing to access the record
>         while it is
>         locked; otherwise it cannot be certain that the update will succeed
>         because the attempt to update the record will fail if another user
>         updates the record first."
>
>         Did I misinterpret how your approach works?
>
>
>     The record is never "locked" in my approach, why is why I don't like
>     to think of it as optimistic locking. It's more like "optimistic
>     read and update with retry if certain conditions continue to be
>     met..." :)
>
>     To be very precise, the record is never locked explicitly -- either
>     through the use of SELECT FOR UPDATE or some explicit file or
>     distributed lock. InnoDB won't even hold a lock on anything, as it
>     will simply add a new version to the row using its MGCC (sometimes
>     called MVCC) methods.
>
>     The technique I am showing in the patch relies on the behaviour of
>     the SQL UPDATE statement with a WHERE clause that contains certain
>     columns and values from the original view of the record. The
>     behaviour of the UPDATE statement will be a NOOP when some other
>     thread has updated the record in between the time that the first
>     thread read the record, and the time the first thread attempted to
>     update the record. The caller of UPDATE can detect this NOOP by
>     checking the number of affected rows, and retry the UPDATE if
>     certain conditions remain kosher...
>
>     So, there's actually no locks taken in the entire process, which is
>     why I object to the term optimistic locking :) I think where the
>     confusion has been is that the initial SELECT and the following
>     UPDATE statements are *not* done in the context of a single SQL
>     transaction...
>
>     Best,
>     -jay
>
>         On Wed, Jul 30, 2014 at 11:07 AM, Jay Pipes <jaypipes at gmail.com
>         <mailto:jaypipes at gmail.com>
>         <mailto:jaypipes at gmail.com <mailto:jaypipes at gmail.com>>> wrote:
>
>              On 07/30/2014 10:53 AM, Kevin Benton wrote:
>
>                  Using the UPDATE WHERE statement you described is
>         referred to as
>                  optimistic locking. [1]
>
>         https://docs.jboss.org/____jbossas/docs/Server_____Configuration_Guide/4/html/____The_CMP_Engine-Optimistic_____Locking.html
>         <https://docs.jboss.org/__jbossas/docs/Server___Configuration_Guide/4/html/__The_CMP_Engine-Optimistic___Locking.html>
>
>         <https://docs.jboss.org/__jbossas/docs/Server___Configuration_Guide/4/html/__The_CMP_Engine-Optimistic___Locking.html
>         <https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/The_CMP_Engine-Optimistic_Locking.html>>
>
>
>              SQL != JBoss.
>
>              It's not optimistic locking in the database world. In the
>         database
>              world, optimistic locking is an entirely separate animal:
>
>         http://en.wikipedia.org/wiki/____Lock_(database)
>         <http://en.wikipedia.org/wiki/__Lock_(database)>
>              <http://en.wikipedia.org/wiki/__Lock_(database)
>         <http://en.wikipedia.org/wiki/Lock_(database)>>
>
>              And what I am describing is not optimistic lock concurrency in
>              databases.
>
>              -jay
>
>
>
>              ___________________________________________________
>              OpenStack-dev mailing list
>              OpenStack-dev at lists.openstack.____org
>              <mailto:OpenStack-dev at lists.__openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>>
>         http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev
>         <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev>
>         <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>
>
>
>
>
>         --
>         Kevin Benton
>
>
>         _________________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.__org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>