Opened 5 years ago

Closed 2 years ago

Last modified 2 years ago

#14165 closed Cleanup/optimization (fixed)

Transaction management is only entered for the primary database

Reported by: sandy@… 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 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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?

comment:2 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:3 Changed 3 years ago by aaugustin

  • Component changed from Database layer (models, ORM) to Documentation
  • Easy pickings unset
  • Needs documentation set
  • Triage Stage changed from Design decision needed to Accepted
  • Type changed from New feature to 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 Changed 2 years ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 2d1214d92ae67acaf2246c3dc2ea37cdf7e1c2a5:

Fixed #14165 - Documented that TransactionMiddleware only applies to the default database.

comment:5 Changed 2 years ago by Tim Graham <timograham@…>

In cf17d5e2676f7ddf71ce0a78bfa0060da718924c:

[1.4.X] Fixed #14165 - Documented that TransactionMiddleware only applies to the default database.

Backport of 938ee7cd36 from master

Note: See TracTickets for help on using tickets.
Back to Top