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" <jaypi...@gmail.com <mailto:jaypi...@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 <jaypi...@gmail.com <mailto:jaypi...@gmail.com> <mailto:jaypi...@gmail.com <mailto:jaypi...@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@lists.openstack.____org <mailto:OpenStack-dev@lists.__openstack.org <mailto:OpenStack-dev@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@lists.openstack.__org <mailto:OpenStack-dev@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@lists.openstack.__org <mailto:OpenStack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
