On Sep 6, 6:52 pm, Preston Holmes <pres...@ptone.com> wrote: > > what about a simple function that does something as low tech as > checking a lock file. If you had multiple front end servers, this > could be a running process on a server using semaphore lock. > > -Preston
Sort of thought about that as well. Meanwhile I found two other solutions to similar problems. One is really high tech and made for GAE[1] dealing with high concurrency counters using memcashed and periodically persisting the counter to database. That solution involves something similar that a lock file would do but still not... The other [2] is on the other hand very low tech and deals with race- conditions in django in a more trial-and-error kind of way that was my first plan for this. Try your best by looking at a previous Max value and take care of the integrity error that might occur. I am really intrigued by the scalability of the first one and the pragmatist in me would go for the second. I really don't want to hit the database for either read or write more then necessary so if I could get a highly probable counter value as default by doing something similar as the GAE[1] approach and just deal with the integrity error when that unlikely event occurs just as option 2 describes. What would the django community go for? It is of course a matter of what scalability and performance requirements you have but what would be the "right" way if you wanted a as pure django solution as possible? All these questions... and to many answers. [1] http://appengine-cookbook.appspot.com/recipe/high-concurrency-counters-without-sharding/ [2] http://stackoverflow.com/questions/3522827/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
