Russell Keith-Magee wrote:
Transactions are a complex subject, and how they behave really depends on the isolation level implemented. (See http://en.wikipedia.org/wiki/Isolation_%28computer_science%29). At the highest isolation level (serializable), transactions do exactly what you want: the database guarantees that the semantics of operations are exactly as if none of them overlapped. Not all databases offer this level of isolation, and it can be difficult to verify that the transactions are performing correctly. And when they do perform correctly, they do so by failing operations (either the UPDATE or the COMMIT) that would violate the isolation guarantees, so your application needs to be prepared to handle those failures in a graceful way, generally by retrying the entire transaction.On 9/10/06, Hawkeye <[EMAIL PROTECTED]> wrote:I don't think that transactions are enough to solve this problem, but I could be wrong.Sorry - I oversimplified your problem in my head. You are correct that transactions wont solve this particular problem by themselves. -- Ned Batchelder, http://nedbatchelder.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~--- |
- Re: Concurrency and data modification Ned Batchelder
- Re: Concurrency and data modification Hawkeye
- Re: Concurrency and data modification Hawkeye
- Re: Concurrency and data modification Michael Radziej
- Re: Concurrency and data modification Joseph Heck
- Re: Concurrency and data modification Hawkeye
- Re: Concurrency and data modification Michael Radziej