Michael Radziej wrote:
>
> What about
> SELECT ... FOR UPDATE
> )
Michael, I know you're already aware of this (heck, you're CCed on the
ticket), but for others...
I created a patch in ticket http://code.djangoproject.com/ticket/2705
to allow a .for_update() modifier to be applied to a QuerySet
On 10/17/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I bet you mean that get_or_create shouldn't lock the table.
> That's really not a good idea.
I meant Django should never implicitly/automatically lock a table; if
you decide you need to lock, you should have to explicitly call
something. I
James Bennett schrieb:
> On 10/17/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
>> Shouldn't there be a function built-in into Django that locks the table
>> (if the database supports it)? IMHO functions like get_or_create()
>> should try to lock and unlock the table automatically.
>
> No, no,
On 10/17/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
> Shouldn't there be a function built-in into Django that locks the table
> (if the database supports it)? IMHO functions like get_or_create()
> should try to lock and unlock the table automatically.
No, no, a thousand times no :)
Even th
Michael Radziej wrote:
> It seems you need to spend more thoughts on multi user issues
> within your application. It's easy to fall for that in the
> beginning, but you need to deal with concurrent access. You must
> be aware for all transactions what impact other transactions can
> have. There is
Thomas Steinacher schrieb:
> James Bennett wrote:
>> On 10/16/06, gabor <[EMAIL PROTECTED]> wrote:
>>> would you use something in the db? (from what i know about transactions
>>> (very little :), they "solve" the potential conflicts by simply
>>> reporting an error-condition to one of the "writers
James Bennett wrote:
> On 10/16/06, gabor <[EMAIL PROTECTED]> wrote:
> > would you use something in the db? (from what i know about transactions
> > (very little :), they "solve" the potential conflicts by simply
> > reporting an error-condition to one of the "writers", so then he has to
> > retry
James Bennett wrote:
> On 10/16/06, gabor <[EMAIL PROTECTED]> wrote:
>> would you use something in the db? (from what i know about transactions
>> (very little :), they "solve" the potential conflicts by simply
>> reporting an error-condition to one of the "writers", so then he has to
>> retry. bu
On 10/16/06, gabor <[EMAIL PROTECTED]> wrote:
> would you use something in the db? (from what i know about transactions
> (very little :), they "solve" the potential conflicts by simply
> reporting an error-condition to one of the "writers", so then he has to
> retry. but is there some simply (mul
James Bennett wrote:
> For truly critical
> operations, I'd probably just go ahead and grab an exclusive lock on
> whatever I needed, and force other transactions to wait.
how would you that?
would you use something in the db? (from what i know about transactions
(very little :), they "solve"
On 10/16/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
> It did not help with the code I posted that was using get_or_create(),
> because I didn't use unique_together... I don't think it would help
> with the money-transfer code.
This is a tricky problem, not least because each of the DBs we s
Thomas Steinacher wrote:
> gabor wrote:
>> Thomas Steinacher wrote:
>>> I already included
>>> "django.middleware.transaction.TransactionMiddleware" in my
>>> MIDDLEWARE_CLASSES (as described on
>>> http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests)
>>> a
gabor wrote:
> Thomas Steinacher wrote:
> > I already included
> > "django.middleware.transaction.TransactionMiddleware" in my
> > MIDDLEWARE_CLASSES (as described on
> > http://www.djangoproject.com/documentation/transactions/#tying-transactions-to-http-requests)
> > and it didn't help.
> >
>
> y
Thomas Steinacher wrote:
> On Oct 16, 2006, at 8:46 PM, gabor wrote:
>>> What, if two Django processes transfer money from account A to account
>>> B simultaneously?
>> these situations are (afaik) handled using transactionssimply start
>> a transaction at the beginning, and commit/rollback at
On Oct 16, 2006, at 8:46 PM, gabor wrote:
> > What, if two Django processes transfer money from account A to account
> > B simultaneously?
>
> these situations are (afaik) handled using transactionssimply start
> a transaction at the beginning, and commit/rollback at the end...
I already incl
On 16/10/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> SQLite is *not* something to be using if proper locking and safe
> concurrent access will be important; SQLite's own docs point out a
> couple of cases where its locking just won't work, and they recommend
> moving to a client-server RDBMS
On 10/16/06, Thomas Steinacher <[EMAIL PROTECTED]> wrote:
> This is my setup:
>
> - Django (SVN) running with "python manage.py runfcgi method=prefork"
> (there are 6 processes running)
> - Lighttpd
> - SQLite
SQLite is *not* something to be using if proper locking and safe
concurrent access will
Thomas Steinacher wrote:
> I know that in this specific case it can be enforced at database level
> using the unique and unique_together properties, but how would you
> handle e.g. this scenario?
>
> 1 def transfer_money(from_id, to_id, amount)
> 2from = models.BankAccount.objects.get(id=fr
18 matches
Mail list logo
