Opened 11 years ago

Closed 10 years 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 Aymeric Augustin)

(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 11 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 by mwaterfall, 11 years ago

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 by Aymeric Augustin, 11 years ago

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 by Tim Graham, 11 years ago

Resolution: needsinfo
Status: newclosed

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

comment:4 by anonymous, 10 years ago

Resolution: needsinfo
Status: closednew

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 by anonymous, 10 years ago

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

comment:6 by cad106uk, 10 years ago

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 by Aymeric Augustin, 10 years ago

Description: modified (diff)

(Fixed formatting.)

comment:8 by Aymeric Augustin, 10 years ago

Resolution: needsinfo
Status: newclosed

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.

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