OperationalError: database is locked

[hnguyen]

How to Reproduce

While doing a GET operation on /query, Trac issued an internal error.

(please provide additional details here)

Request parameters:

{'group': u'status',
 'milestone': u'milestone1',
 'status': [u'assigned', u'new', u'accepted', u'reopened']}

User agent: #USER_AGENT#

System Information

Trac	0.12rc1
Babel	0.9.5
Docutils	0.6
Genshi	0.6
mod_python	3.3.1
Pygments	1.3.1
pysqlite	2.3.2
Python	2.5.2 (r252:60911, Jan 20 2010, 23:30:56) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)]
pytz	2010h
setuptools	0.6c11
SQLite	3.4.2
Subversion	1.6.11 (r934486)
jQuery	#JQUERY#

Enabled Plugins

TracAccountManager	0.2.1dev-r7737
TracSpamFilter	0.3.2dev-r9922

Python Traceback

Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 258, in dispatch
    req.session.save()
  File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 88, in save
    @self.env.with_transaction()
  File "build/bdist.linux-x86_64/egg/trac/db/api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 110, in delete_session_cookie
    """, (self.sid,))
  File "build/bdist.linux-x86_64/egg/trac/db/util.py", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 78, in execute
    result = PyFormatCursor.execute(self, *args)
  File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 56, in execute
    args or [])
  File "build/bdist.linux-x86_64/egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database is locked

[Christian Boos]

How frequent is this? If not exceptional, try to easy_install pysqlite, this will give you 2.6.0 instead of 2.3.2 you're currently using, and see if it reduces the rate of the problem.

[Christian Boos]

Anyway, duplicate of #3446. The next iteration of the db code (#9536) should theoretically improve the situation, we'll see.