Hey Maciej, 2010/1/8 Maciej Sobczak <[email protected]>: > It would work by encapsulating your locking logic in terms of whatever > code it takes to do it, and by returning a boolean flag stating whether > it was done successfully. From the client perspective the call would > look like any other statement that reads some boolean variable.
So, basically: optimistic locking does not really take locks, it only works to detect possible concurrent modifications (rather than pessimistically preventing them). See: http://en.wikipedia.org/wiki/Optimistic_concurrency_control and http://cwiki.apache.org/CAY/optimistic-locking-explained.html ASFAIK, optimistic concurrency control is the most widely form of locking used for web applications because you do not need to take database locks while the user is thinking (and since HTTP is a stateless protocol, you cannot know whether the user's browser has crashed or whether he is in fact thinking very long). Therefore it has only a very low impact on database performance since you do not need to take database locks. It requires active support in a table, by having an extra column, and thus is not something you would do "behind the back". It also requires that SQL update and SQL delete statements take the mechanism into account to check for the correct version/timestamp, and if applicable to update the version field/timestamp. But to be clear: I am only looking for get_affected_row_count() to be supported by SOCI, not optimistic locking... >> Do I have to implement this differently for every >> database? > > Probably yes, because databases differ in their support for stored > procedures. > >> Does every database support stored procedures? > > Probably not, which is the disadvantage if you plan to transparently > target many database types in your application. Yes, that would be the plan. Wt::Dbo is an ORM layer that should support multiple databases. It supports optimistic locking in a way that is (mostly) transparent to the developer. >> Would you consider accepting a patch for SOCI that adds this API call >> and implements it for all the backends ? > > Of course and I would consult it with the rest of the team (which is > reading this mailing list anyway). > >>> Isn't the above scenario a bit too low-level? >> >> I'm not sure I understand how this can be too low-level? > > What do you try to achieve with this locking technique? I would like to implement a really common concurrency detection solution, see supra. Regards, koen ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
