Opened 7 years ago

Closed 2 years ago

#8320 closed Bug (fixed)

Admin Transaction Management Error

Reported by: holdenweb Owned by: aaugustin
Component: contrib.admin Version: master
Severity: Normal Keywords: admin transaction
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by mtredinnick)

When using admin from the trunk [r8346] on Ubuntu I am getting occasional tracebacks like the following. I *appears* only to happen when one of the foreign key fields is changed, or at least I haven't been able to trigger the problem without changing one of them. I am only selecting values using the drop-downs populated from the related models.

Environment:

Installed Applications:

['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'pages',
 'grp',
 'contact',
 'registration',
 'accounts']

Installed Middleware:

('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.middleware.doc.XViewMiddleware')

Traceback:

File "/home/holdenwe/django-trunk/django/core/handlers/base.py" in get_response
  86.                 response = callback(request, *callback_args, **callback_kwargs)
File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in root
  172.                 return self.model_page(request, *url.split('/', 2))
File "/home/holdenwe/django-trunk/django/views/decorators/cache.py" in _wrapped_view_func
  44.         response = view_func(request, *args, **kwargs)
File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in model_page
  189.         return admin_obj(request, rest_of_url)
File "/home/holdenwe/django-trunk/django/contrib/admin/options.py" in __call__
  275.             return self.change_view(request, unquote(url))
File "/home/holdenwe/django-trunk/django/db/transaction.py" in _commit_on_success
  251.             leave_transaction_management()
File "/home/holdenwe/django-trunk/django/db/transaction.py" in leave_transaction_management
  75.         raise TransactionManagementError("Transaction managed block ended with pending COMMIT/ROLLBACK")

Exception Type: TransactionManagementError at /admin/accounts/userprofile/14/
Exception Value: Transaction managed block ended with pending COMMIT/ROLLBACK

Attachments (2)

admin.py (209 bytes) - added by holdenweb 7 years ago.
accounts/admin.py
models.py (1.0 KB) - added by holdenweb 7 years ago.
accounts/models.py

Download all attachments as: .zip

Change History (17)

Changed 7 years ago by holdenweb

accounts/admin.py

Changed 7 years ago by holdenweb

accounts/models.py

comment:1 Changed 7 years ago by mtredinnick

  • Component changed from Uncategorized to Admin interface
  • Description modified (diff)
  • milestone changed from 1.0 maybe to 1.0
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

(Fixed description to stop my eyes watering.)

Putting this on the 1.0 track because if it can ever be reliably repeated we should definitely fix it. That first part is going to be the trick, of course. Finding the right 'component' is a little tough, since we don't quite know where the problem lies. Making it admin for now, since that's the visible symptom at least.

comment:2 Changed 7 years ago by msaelices

I tried to reproduce, with an application with these models and admin, but I cannot reproduce this error.

@holdenweb: ¿Can you give a complete demo app with fixtures inside? And there would be useful a list of steps to reproduce it.

comment:3 Changed 7 years ago by gkelly

I am unable to reproduce using psycopg2 and postgresql 8.2.

holdenweb: what database engine are you using? Perhaps your entire settings.py would also be useful, with the complete demo app requested above too.

comment:4 Changed 7 years ago by jacob

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

I know Steve (aka holdenweb) well enough to know that this isn't to be dismissed lightly. However, without further information we can't reproduce this, so I'm going to mark worksforme until we get any more info.

comment:5 Changed 7 years ago by jacob

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Right, we've got a working test case:

class Parent(models.Model):
    name = models.CharField(max_length=10)
    other_value = models.IntegerField(unique=True)

    def __unicode__(self):
        return u"XXX: %s" % self.name

class Child(Parent):
    father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
    value = models.IntegerField()

    def __unicode__(self):
        return self.name

The bug looks to be related to the combination of parent_link and to_field; editing a Child in the admin will through transaction management errors intermittently.

comment:6 Changed 7 years ago by mtredinnick

  • milestone changed from 1.0 to post-1.0

We know what the problem is here (in django.db.models.base.Model.save()), but attempting to fix it now is just too risky. So this is going in as a "known issue" for 1.0. If the above example is the only way to trigger it, it's an extreme edge case and can be avoided by just not doing that for now.

comment:7 Changed 7 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:8 Changed 6 years ago by anonymous

The problem can also hit when there's an error in the database schema. I just had a case where there was a broken constraint in the database and the fact that there's an Exception thrown in the finally block in _commit_on_success meant that instead of the real error from my database driver (postgresql_psycopg2) I saw the generic and not at all helpful error here. Sucks.

comment:9 Changed 4 years ago by anonymous

  • Severity set to Normal
  • Type set to Uncategorized

If somebody came to this issue maybe: http://code.djangoproject.com/ticket/6623 will help something. I got problems in Django 1.3 / PostgresSQL, there is problem with commit_manually decorator - it hides real exception which in my case was MultipleObjectsFound thrown by .get() function...

comment:10 Changed 4 years ago by lukeplant

  • Type changed from Uncategorized to Bug

comment:11 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:12 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:13 Changed 2 years ago by aaugustin

  • Status changed from reopened to new

comment:14 Changed 2 years ago by aaugustin

  • Owner changed from nobody to aaugustin
  • Status changed from new to assigned

comment:15 Changed 2 years ago by Aymeric Augustin <aymeric.augustin@…>

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

In 14cddf51c5f001bb426ce7f7a83fdc52c8d8aee9:

Merged branch 'database-level-autocommit'.

Fixed #2227: atomic supports nesting.
Fixed #6623: commit_manually is deprecated and atomic doesn't suffer from this defect.
Fixed #8320: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10744: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10813: since autocommit is enabled, it isn't necessary to rollback after errors any more.
Fixed #13742: savepoints are now implemented for SQLite.
Fixed #13870: transaction management in long running processes isn't a problem any more, and it's documented.
Fixed #14970: while it digresses on transaction management, this ticket essentially asks for autocommit on PostgreSQL.
Fixed #15694: atomic supports nesting.
Fixed #17887: autocommit makes it impossible for a connection to stay "idle of transaction".

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