#1661 closed defect (worksforme)
Database locks after an error involving database with mod_python
Reported by: | sam | Owned by: | Christian Boos |
---|---|---|---|
Priority: | highest | Milestone: | |
Component: | web frontend/mod_python | Version: | 0.9.4 |
Severity: | critical | Keywords: | database locked |
Cc: | sam@…, alexander.neundorf@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
After a Trac Oops error involving a database operation (such as page edition, generally occuring with concurrent page edition), the database is not closed by mod_python. According to cmlenz, it is the expected behavior because of the connection pool.
But what's not expected is that the DB is then locked for a couple of minutes or until Apache is restarted.
Additionnal information
Trac version: trunk/ r1784
Sqlite: 2.8.16-1
, from Debian Sid package
Python-sqlite: 1.0.1-2
, from Debian Sid package
[Sun Jun 12 14:26:06 2005] [notice] Apache/2.0.54 (Debian GNU/Linux) DAV/2 SVN/1.1.4 mod_python/3.1.3 Python/2.3.5 PHP/4.3.10-15 mod_ssl/2.0.54 OpenSSL/0.9.7g mod_perl/1.999.23 Perl/v5.8.7 configured -- resuming normal operations
Attachments (0)
Change History (9)
comment:1 by , 20 years ago
comment:2 by , 19 years ago
Keywords: | database locked added |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
…generally occuring with concurrent page edition
This situation is much better handled now in Trac 0.9
and above, especially when using PySqlite version ≥ 2.0.5
and SQLite compiled after having set the --enable-threadsafe
configuration switch on Unix/Linux (the Windows version
being threadsafe by default).
comment:3 by , 19 years ago
Cc: | added |
---|---|
Priority: | high → highest |
Resolution: | worksforme |
Status: | closed → reopened |
Version: | devel → 0.9.4 |
We get the same error. We have installed trac 0.9.4, sqlite 3.3.4 and pysqlite 2.1.3 on a SUSE 9.0. sqlite was compiled with —enable-threadsafe. Trac is installed as fastcgi with apache 2. The problem is usually noticed when somebody tries to login to trac.
Oops... Trac detected an internal error: database is locked If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team. Go to http://trac.edgewall.com/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below. TracGuide 227 The Trac User and Administration Guide Python traceback Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/trac/web/fcgi_frontend.py", line 40, in _handler dispatch_request(req.path_info, req, env) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 82, in process_request self._do_login(req) File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 118, in _do_login db.commit() OperationalError: database is locked
comment:4 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
Is this still happening? Are the locks "persistent" (i.e. all subsequent requests fail with this error) or does this only happen occasionally?
comment:5 by , 19 years ago
Yes, it still happens, but quite seldom. After this all requests fail. After stopping apache there are still some trac.fcgi hanging around, which can't be killed normally, but SIGKILL has to be used. Then it works again.
Unfortunately I have no idea how to reproduce it. The one who is the first to get this error probably didn't cause it I think.
comment:6 by , 19 years ago
It just happened again. It appeared when somebody tried to login.
Oops… Trac detected an internal error:
database is locked
If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team.
Go to http://trac.edgewall.com/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below.
TracGuide The Trac User and Administration Guide Python traceback
Traceback (most recent call last):
File "/usr/lib/python2.3/site-packages/trac/web/fcgi_frontend.py", line 40, in _handler
dispatch_request(req.path_info, req, env)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
dispatcher.dispatch(req)
File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
resp = chosen_handler.process_request(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 82, in process_request
self._do_login(req)
File "/usr/lib/python2.3/site-packages/trac/web/auth.py", line 118, in _do_login
db.commit()
OperationalError: database is locked
comment:7 by , 19 years ago
alexander, the usual question: what SQLite and PySqlite versions are you using? It looks like you're using the trunk version of Trac. What revision exactly?
comment:8 by , 18 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I'm going to close this, as we lack detailed information; if someone still experience locks that persist and requires a server restart, please provide us with all the detailed information we need.
We believe that with the recent versions of SQLite and PySqlite, there are no more persistent locks. Transient OperationalError: database is locked
are unfortunately quite common (see #3446 and #3503).
comment:9 by , 15 years ago
Hm seems something like that is regularlyh happening for me at http://vamos1.informatik.uni-erlangen.de/trac/linux which is Ubuntu karmic's setup of trac with trac-git deployed via mod_wsgi
BTW: This does not happen with SQLite 3.