TransactionRollbackError on /auth/complete causes OOPS and OpenID login failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu One Servers |
Triaged
|
Medium
|
Unassigned |
Bug Description
This bug report serves as a master bug report for the issues with logging in that were caused by TransactionRoll
These errors are temporary, usually next attempt will succeed but this definitely needs to be looked into and find why the transaction took that long.
Traceback is:
Module /srv/ubuntuone.
cursor.
Module /srv/ubuntuone.
self.
Module /srv/ubuntuone.
self.
Module /srv/ubuntuone.
del_
Module /srv/ubuntuone.
delete_
Module /srv/ubuntuone.
Session.
Module /srv/ubuntuone.
self.
Module /srv/ubuntuone.
request.
Module /usr/lib/
auth_
Module /srv/ubuntuone.
response = callback(request, *callback_args, **callback_kwargs)
Module /srv/ubuntuone.
response = self.get_
Module /var/lib/
return self.applicatio
TransactionRoll
visibility: | private → public |
Changed in ubuntuone-servers: | |
status: | New → Triaged |
Changed in ubuntuone-servers: | |
assignee: | Registry Administrators (registry) → nobody |
This appears to be coming from the django-openid code package and not any of our specific code.
On 07/27/2010 05:33 AM, Roman Yepishev wrote: backError on the server- com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ db/models/ sql/query. py, line 1734, in execute_sql com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ db/models/ sql/subqueries. py, line 34, in do_query sql(None) com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ db/models/ sql/subqueries. py, line 86, in delete_batch query(self. model._ meta.db_ table, where) com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ db/models/ query.py, line 870, in delete_objects delete_ batch(pk_ list) com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ db/models/ base.py, line 443, in delete objects( seen_objs) com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ contrib/ sessions/ backends/ db.py, line 71, in delete objects. get(session_ key=session_ key).delete( ) com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ contrib/ sessions/ backends/ base.py, line 250, in cycle_key com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ contrib/ auth/__ init__. py, line 64, in login session. cycle_key( ) python2. 5/site- packages/ django_ openid_ auth/views. py, line 209, in login_complete com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ core/handlers/ base.py, line 86, in get_response com/production/ ubunet- rev-2946/ utilities/ ../lib/ django/ core/handlers/ wsgi.py, line 239, in __call__ response( request) python- support/ python2. 5/paste/ translogger. py, line 67, in __call__ n(environ, replacement_ start_response) backError: ' could not serialise access due to concurrent update'
> Public bug reported:
>
> This bug report serves as a master bug report for the issues with
> logging in that were caused by TransactionRoll
> side.
>
> These errors are temporary, usually next attempt will succeed but this
> definitely needs to be looked into and find why the transaction took
> that long.
>
> Traceback is:
> Module /srv/ubuntuone.
> cursor.execute(sql, params)
> Module /srv/ubuntuone.
> self.execute_
> Module /srv/ubuntuone.
> self.do_
> Module /srv/ubuntuone.
> del_query.
> Module /srv/ubuntuone.
> delete_
> Module /srv/ubuntuone.
> Session.
> Module /srv/ubuntuone.
> self.delete(key)
> Module /srv/ubuntuone.
> request.
> Module /usr/lib/
> auth_login(request, user)
> Module /srv/ubuntuone.
> response = callback(request, *callback_args, **callback_kwargs)
> Module /srv/ubuntuone.
> response = self.get_
> Module /var/lib/
> return self.applicatio
> TransactionRoll
>
> ** Affects: ubuntuone-servers
> Importance: Medium
> Assignee: Ubuntu One web team (ubuntuone-web)
> Status: New
>
> ** Visibility changed to: Public
>