Code

Opened 14 months ago

Closed 4 months ago

#20373 closed Bug (needsinfo)

Simple Multi-DB read replica unit test raises TransactionManagementError

Reported by: TTimo Owned by: nobody
Component: Testing framework Version: 1.5
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by aaugustin)

(I posted this on the ML initially, but I suspect it's a bug in the testing framework. A complete example is attached. Empty unit test, with no routers and a read replica DB setup gives a TransactionManagementError)

--

I started assessing multi-db support in Django 1.5.1, I'm interested in having read replicas and a write master.

I've figured out all the easy stuff: using TEST_MIRROR in the DATABASES setting, writing a simple router that splits read and write traffic, all according to the documentation. I can run a test server and issue some calls manually, but I have not been able to run simple unit tests.

The most simple test I can build fails during _pre_setup() with a "TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK"

My databases are MySQL EC2 RDS instances, the replication is working fine, the tables are InnoDB etc.

I know there is active development around transaction management code in Django lately, so maybe I've stumbled on a bug? I'm attaching a simple test setup that should make it easy to reproduce.

Any advice would be greatly appreciated.

Cheers,
TTimo

./manage.py test readreplica
Creating test database for alias 'default'...
E
======================================================================
ERROR: testTest (readreplica.tests.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py", line 240, in __call__
    self._pre_setup()
  File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py", line 462, in _pre_setup
    self._fixture_setup()
  File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py", line 822, in _fixture_setup
    if not connections_support_transactions():
  File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py", line 809, in connections_support_transactions
    for conn in connections.all())
  File "/usr/local/lib/python2.7/dist-packages/django/test/testcases.py", line 809, in <genexpr>
    for conn in connections.all())
  File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 48, in __get__
    res = instance.__dict__[self.func.__name__] = self.func(instance)
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 627, in supports_transactions
    self.connection.leave_transaction_management()
  File "/usr/local/lib/python2.7/dist-packages/django/db/backends/__init__.py", line 319, in leave_transaction_management
    "Transaction managed block ended with pending COMMIT/ROLLBACK")
TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK

----------------------------------------------------------------------
Ran 0 tests in 0.084s

FAILED (errors=1)
Destroying test database for alias 'default'...

Attachments (1)

readreplica-unittest-transactionerror.tgz (3.6 KB) - added by TTimo 14 months ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 13 months ago by mwaterfall

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I'm also experiencing this issue. The ticket has been opened for 7 weeks without a reply which is a bit concerning :S

comment:2 Changed 13 months ago by aaugustin

This cannot be a side effect of the recent work on transaction management, since that work didn't touch the stable/1.5.x branch.

The previous transaction management was so buggy that it was entirely removed and replaced. That could explain why there's little interest in fixing it...

comment:3 Changed 12 months ago by timo

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

As noted above, please re-open if this is still an issue with Django 1.6.

comment:4 Changed 5 months ago by anonymous

  • Resolution needsinfo deleted
  • Status changed from closed to new

I've experienced the same bug on both django 1.5 and django 1.6 I too am using multi-db read replica with TEST_MIRROR set. If I remove the slave and the db router the test runs fine.

comment:5 Changed 5 months ago by anonymous

Also this captcha like math equation for spam often fails here if the result is supposed to be a negative number.

comment:6 Changed 5 months ago by cad106uk

I had this problem this morning. For me it turned out not to be a problem with my django install. It turned out to be a problem with my .sqlite3 file. When I deleted this file and ran the tests again the problem went away.

comment:7 Changed 4 months ago by aaugustin

  • Description modified (diff)

(Fixed formatting.)

comment:8 Changed 4 months ago by aaugustin

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

After changing the settings file to:

SECRET_KEY='oh hay this is a test'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'django_test',
        'USER': 'root',
        },
    'slave': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'django_other',
        'USER': 'root',
        # https://docs.djangoproject.com/en/dev/topics/testing/advanced/#topics-testing-masterslave
        'TEST_MIRROR' : 'default',
        },
    }

INSTALLED_APPS = ['readreplica']

The example works for me on Django 1.7:

(django-dev)myk@mYk readreplica % ./manage.py test --settings=settings                               ~/Documents/dev/django/readreplica
Creating test database for alias 'default'...
testTest
.
----------------------------------------------------------------------
Ran 1 test in 0.054s

OK
Destroying test database for alias 'default'...

Since this was reopened anonymously there's nothing we can do about it.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.