8

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?

RichVel
  • 7,030
  • 6
  • 32
  • 48
Trent
  • 2,328
  • 3
  • 33
  • 51

1 Answers1

9

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.

orokusaki
  • 55,146
  • 59
  • 179
  • 257
  • That's what I thought the documentation was saying, but if that's true, doesn't that render the select_for_update function pretty useless (as its original reason was to lock affected rows until a write operation was executed) – Trent Jun 19 '13 at 06:00
  • 2
    @Taras - `select_for_update` does exactly as it's documented to do, but if you use it with autocommit, you're essentially getting and releasing the lock all at once, which isn't much help. So, the query operates all the same, but without a transaction to maintain a sort of state, how would Postgres know when to release the lock (other than immediately)? If it just held them until a write, imagine a bad program that selected a bunch of rows for update and then raises an exception. The selected rows would be locked forever. – orokusaki Jun 19 '13 at 14:07
  • I think I understand now. `select_for_update` isn't useful with autocommit, but it **is** useful for when the autocommit behaviour isn't being used, eg: when the transaction is explicitly defined via an `atomic` statement..? – Trent Jan 27 '14 at 05:37
  • Why does the documentation consider this an extremely fragile design? It seems like wrapping select_for_update in a transaction with a subsequent write operation is the *only* thing that makes select_for_update worthwhile. Otherwise, why even bother with it? – Nick Fishman Apr 09 '14 at 22:26
  • @NickFishman that's exactly what I thought. Can someone explain how to actually use select_for_update? – Cesar Apr 19 '14 at 23:08
  • 1
    @NickFishman I've clarified over at https://stackoverflow.com/questions/23591365/django-1-5-select-for-update-considered-fragile-design/23854925#23854925 – Trent May 25 '14 at 11:54