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? On Wed, Jul 30, 2014 at 11:07 AM, Jay Pipes <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 >> > > 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) > > And what I am describing is not optimistic lock concurrency in databases. > > -jay > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
