"Think distributed: two requests updating the same data concurrently. Last write wins. Data might not be what you expect, as you can't make sure that you have the version you directly read before updating. This is the simple scenario. Often this doesn't matter, as "last write wins" is quite acceptable. But sometimes - for example if you do financial transactions or shop stuff - this might be quite undesirable. But even then it might not hit you, as this is a solely update-related problem - it won't happen with inserts, as you usually have automatically generated id's and so concurrent inserts will get separate id's.
And it can't be really solved without transactions, as you would need to be able to make sure that your fetched object is still the correct version that's in the database." If you're talking about starting a transaction that locks the record on the db when a user begins to view/edit a record, and commits transaction when user posts changes, then this would be a terrible way to go for a web app, in my opinion. Works okay for client/server situations, but it's hard to implement and drastically affects the scalability advantage a web app has over c/s. The best method is to simulate optimistic locking in the db. The two ways I've seen the problem of simulating optimistic locking solved are: (1) have timestamp field in db that is used to identify record, along with primary key. E.g., UPDATE _tbl_ . . . WHERE primarykeyval = [value] and lastchangedval = [timestampval]. This way the record won't be found if it has been updated since second user got his copy (assuming timestamp is updated in every update). (2) the second way doesn't involve using a timestamp field at all, it just requires putting the pre-edited value of every non-blob field in the where clause (won't work for blobs) whenever you do an update or delete. This way if one of the fields has changed in meantime the record simply won't be found and an error can be returned. This requires having pre-edited value of any changed fields to include when the updates where clause is created. -- Herb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
