Jacob -- I'm a mostly non-web programmer (with experience in non-web n-tier apps) trying to figure out exactly what sort of transaction support this is. Can you clarify for me? Here are the two types of transactions I'm thinking people might want:
(1) Transaction is begun when a client makes a request from the webserver. The webserver maintains the connection to the db (and the db locks associated records or tables) until response is received back from client. At that point the changes are applied, the transaction is committed, and the connection is released. Because a client ties up a connection from point of time between request from webserver and time that changes are sent back, this is not a method that can scale very well. (2) Transaction is not begun until client returns changes to apply them to database. The changes are applied to multiple records, perhaps master/detail, all within the same transaction. Then transaction is committed. If there's error then things are rolled back; thus no change to master table or to detail table without guarantee that all are made. Since this method maintains open transaction only for brief period to apply changes in response sent from client it is very scalable. Unlike method (1) above there are no long-open transactions and connections are not generally tied up by open transactions. The downside is that there is no locking within the db when a user retrieves a request from the webserver. So you have to simulate some sort of optimistic locking outside the db. I'm trying to figure out what sort of transaction support you're creating for Django. I have no desire or need to use option (1). It works okay for client/server apps with relatively small numbers of users, but I think it's bad programming practice for a disconnected or distributed application, as any web app is. With transaction support of type (2) you get the guarantee that any set of changes will be applied in an atomic all-or-nothing way, but you have the problem that the db itself isn't doing any locking. This can be worked around fairly easily by using timestamp fields on records in addition to a primary key, I think. And this method is very scalable,l unlike method (1). Thanks for any clarification. -- 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 -~----------~----~----~----~------~----~------~--~---
