问题
The Django documentation states that:
If you were relying on “automatic transactions” to provide locking between select_for_update() and a subsequent write operation — an extremely fragile design, but nonetheless possible — you must wrap the relevant code in atomic().
Is the reason why this no longer works is that autocommit is done at the database layer and not the application layer? Previously the transaction would be held open until a data-altering function is called:
Django’s default behavior is to run with an open transaction which it commits automatically when any built-in, data-altering model function is called
And since Django 1.6, with autcommit at the database layer, that a select_for_update followed by for example a write would actually run in two transactions? If this is the case, then hasn't select_for_update become useless as its point was to lock the rows until a data altering function was called?
回答1:
select_for_update will only lock the selected row within the context of a single transaction. If you're using autocommit, it won't do what you think it does, because each query will effectively be its own transaction (including the SELECT ... FOR UPDATE query). Wrap your view (or other function) in transaction.atomic and it'll do exactly what you're expecting it to do.
来源：https://stackoverflow.com/questions/17149587/select-for-update-in-development-django