#14165 closed Cleanup/optimization (fixed)
Transaction management is only entered for the primary database
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Documentation | Version: | 1.2 |
Severity: | Normal | Keywords: | transactions, middleware, multidb |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | yes |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Problem:
TransactionMiddleware calls enter_transaction_management() with no parameters, which results in transaction management only being entered for the default database.
class TransactionMiddleware(object): def process_request(self, request): """Enters transaction management""" transaction.enter_transaction_management() transaction.managed(True)
When writing to databases that are not the "default", transactions are not managed.
Proposed Solution:
To default to non-managed transactions for databases other than "default".
Change History (5)
comment:1 by , 14 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:3 by , 13 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Easy pickings: | unset |
Needs documentation: | set |
Triage Stage: | Design decision needed → Accepted |
Type: | New feature → Cleanup/optimization |
UI/UX: | unset |
As soon as you're using several databases, you can't be fully ACID any longer.
I think it's best to keep TransactionMiddleware simple and document the current behavior.
That should be sufficient, given the rather low attention this ticket has gotten over one year.
Accepting as a documentation ticket.
comment:4 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
There is a design decision needed here. The TransactionMiddleware clearly wasn't designed with multiple databases in mind.
I don't think the fix is as simple as just making all non-default databases non-managed; that implies a bunch of assumptions about non-default databases that I'm not convinced hold in the general case (or even in the common case).
Documenting the single-database nature of the TransactionMiddleware would be the easist solution; if you have more than one database, you may need to write your own TransactionMiddleware that will operate in the way you want it to behave.
Alternatively, it might be possible to define a configuration mechanism for TransactionMiddleware, defining which databases need to be put into management, etc. My concern here is what happens on the error case -- how do we describe, in a general fashion, what happens if DB2 is rolled back -- do we then roll back DB1? What happens if DB1 has already been committed?