On Thu, Feb 11, 2010 at 8:55 AM, khoobks <khoo...@gmail.com> wrote:
> Hi Everyone,
>
> I was wondering if a Django guru was able to verify if my mental model
> of how django transactions operate is correct.
>
> The situation that I have is that I'd like to place the
> transaction.commit_on_success decorator around a custom function on my
> model. At the same time, I would also like to enable the
> TransactionMiddleware for my views. The former would protect the
> database from invalid states while using the shell while the latter
> would protect the database if a view function happens to raise an
> exception.
>
> The part where I am particularly concerned is what will happen if a
> view function calls a model function with the commit_on_success
> decorator set. If the model function executes correctly but the view
> function fails, will the database roll back to the state before the
> view function started - or will the changes performed by the model
> function persist.
>
> My thinking (and looking at the django source) is that transaction
> state is being managed as a stack and therefore you can enter a
> managed block N times and until you also leave transaction management
> N times, nothing at all will be committed. So in the above situation,
> everything will be fine and the database will be in the state as if
> the view never happened.
Not quite.
There is a stack, but the stack is used to make sure that
enter_transaction_management() and leave_transaction_management()
calls are balanced, and that the transaction management state that
existed pre-enter is the same that exists post-leave.
Django itself will only ever have a single transaction open. When a
successful action completes,
It's easier to demonstrate with an example mirroring the use case you
describe. In the following, testview() is deployed in a setup where
TransactionMiddleware is in use.
@transaction.commit_on_success
def do_stuff():
p = Person(name='Alice')
p.save()
def testview(request):
p = Person(name='Bob')
p.save()
do_stuff()
p2 = Person(pk=p.pk, name='Chuck')
p2.save(force_insert=True)
return HttpResponse('OK')
In this setup, the call to do_stuff() succeeds. The commit_on_success
decorator kicks in, causing a commit. However, the commit includes
both the creation of Alice and Bob.
When the creation of Chuck fails, it raises an exception, which is
caught by the TransactionMiddleware, causing a rollback -- to the
state at the end of the last commit, which was the end of the
do_stuff() call.
So, calling this view will create two objects in your database.
If the only reason for using @commit_on_success is to avoid problems
in the shell, and you're using Postgres, it might be worth looking
into database autocommit mode. This will allow you to use
transactions, but when you're not in a transaction, each write will be
isolated, so you won't have to mess around with rollbacks at the
shell. Depending on the usage pattern of your queries, there might
even be a performance benefit - read heavy sites should see a slight
boost from autocommit mode.
[1] http://docs.djangoproject.com/en/1.1/ref/databases/#autocommit-mode
Yours,
Russ Magee %-)
--
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.
