#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---------------------------------------------------+------------------------
Reporter: ishirav | Owner:
mtredinnick
Status: assigned | Milestone: 1.3
Component: Database layer (models, ORM) | Version: 1.0-beta-1
Resolution: | Keywords:
transactions
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------------------------+------------------------
Comment (by shai):
Replying to [comment:45 jacob]:
> We just need a specific mechanism to commit un-committed connections
upon close.
I beg to differ.
* Under manual control, we don't want to commit un-committed transactions
-- we want to throw a `TransactionManagementError` like we always did.
* Under `commit_on_success`, we don't want to wait for the connection to
close -- we want to commit or rollback as soon as we leave the function.
The user may still perform other operations on this connection, and they
should go in separate transactions (I'm ignoring nested transaction
management blocks here for simplicity).
Unless I'm missing something, these two points mean that whatever we do
has to take care of what happens whenever a transaction management block
ends. Considering also the possibility of more than one transaction, I
think the only way to go is to make sure transactions are marked dirty
when they should be.
This still leaves an option that uses no notification: Just consider the
connection to be always in "dirty" state, so action is taken whenever a
transaction management block ends. I went this road in my first patches;
it has two ill effects.
* One is, again, it loses the enforcement of correct transaction
management under manual control, an important development aid;
* The second is that we must choose, at the closing of the connection,
between closing the transaction and not closing it. Because of the first
problem, not closing allows manually-controlled transactions to be left
dangling, whereas closing means that correctly-managed transactions will
be closed twice -- and that second closing is a DB round-trip.
Thus, I see no viable alternative to notifying the transaction-management
mechanism whenever a cursor is used.
--
Ticket URL: <http://code.djangoproject.com/ticket/9964#comment:46>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
