Roundup Tracker - Issues

Message2425

Author schlatterbeck
Recipients
Date 2007-08-15.09:50:46
Message-id
In-reply-to
I'm seeing the same on a busy tracker several times a day.
System: Debian Etch (Stable) with psycopg 1.1.18

If I try to ignore the errors (by creating a sessions_postgresql.py where I catch the exception) I'm getting from time to time -- (but the original errors on session management seem to be gone) errors about otk (one time key) management:

Traceback (most recent call last):

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 258, in inner_main
    self.determine_user()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 448, in determine_user
    self.clean_sessions()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 353, in clean_sessions
    self.db.getOTKManager().clean(now)

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/backends/sessions_postgresql.py", line 45, in clean
    BaseBasicDatabase.clean(self, now)

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/backends/sessions_rdbms.py", line 92, in clean
    self.name, self.db.arg), (old, ))

ProgrammingError: ERROR:  current transaction is aborted, commands ignored until end of transaction block

delete from otks where otk_time < 1186448402.04

So I guess, the OTK and Session management code should run in its own transaction. Is somebody fluent enough in the psycopg framework to create a separate cursor with its own transaction for the session management? It looks to me like the cursor in question is running in auto-commit mode, otherwise the error would be raised on commit not on cursor.execute?

For the record, these are the tracebacks seen with the original code,
three different tracebacks with the original code:

Traceback (most recent call last):

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 258, in inner_main
    self.determine_user()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 448, in determine_user
    self.clean_sessions()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 352, in clean_sessions
    sessions.clean(now)

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/backends/sessions_rdbms.py", line 92, in clean
    self.name, self.db.arg), (old, ))

ProgrammingError: ERROR:  could not serialize access due to concurrent update

delete from sessions where session_time < 1184374803.64


Traceback (most recent call last):

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 258, in inner_main
    self.determine_user()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 486, in determine_user
    sessions.updateTimestamp(self.session)

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/backends/sessions_rdbms.py", line 85, in updateTimestamp
    (now, infoid, now-60))

ProgrammingError: ERROR:  could not serialize access due to concurrent update

update sessions set session_time=1184837598.64 where session_key='MTE4MzYyMDMxNy40NTAuMjI0MjUyNDMzNzMy'
            and session_time < 1184837538.64


Traceback (most recent call last):

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 258, in inner_main
    self.determine_user()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 448, in determine_user
    self.clean_sessions()

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/cgi/client.py", line 354, in clean_sessions
    sessions.set('last_clean', last_use=time.time())

  File "/roundup/sw/python2.4//lib/python2.4/site-packages/roundup/backends/sessions_rdbms.py", line 73, in set
    c.execute(sql, args)

ProgrammingError: ERROR:  could not serialize access due to concurrent update

update sessions set session_value='{''last_use'': 1184806806.3256691}' where session_key='last_clean'

History
Date User Action Args
2009-02-03 14:22:04adminlinkissue1703116 messages
2009-02-03 14:22:04admincreate