I'm reminded that almost all my own disasters were caused by premature
optimisation.
I would go with the simplest solution and keep an eye on performance as
it scales. Gives you plenty of time to research plan B.
That'll be 2c please
M
On 7/09/2010 4:49am, kmpm wrote:
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.
