Opened 18 years ago
Closed 4 years ago
#3444 closed defect (worksforme)
Strange `database is locked` error: commit fails but data is nevertheless saved...
Reported by: | Christian Boos | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | database backend | Version: | devel |
Severity: | normal | Keywords: | database lock pysqlite weird |
Cc: | trac@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I just tried to close #3410, and I got the following error message:
Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 314, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 199, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 260, in process_request self._do_save(req, db, ticket) File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 530, in _do_save db.commit() OperationalError: database is locked
So far so good (well…) but when looking at the timeline immediately after that, the change appears to have succeeded! And that's really puzzling: if the commit fails, the data shouldn't persist.
This is not the first time I see somthing like this, so now I've decided to create a ticket about it. No milestone set, it's just a place to record the issue and discuss it until what happens is understood…
Attachments (0)
Change History (9)
comment:1 by , 18 years ago
Version: | 0.9.6 → devel |
---|
comment:2 by , 18 years ago
Cc: | added |
---|
comment:3 by , 18 years ago
The database is locked
error was addressed in #3503. Can you upgrade to the version specified in that ticket and see if this issue still exists for you?
comment:4 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The reporter obviously knows about #3503, as he fixed that issue… so I guess the upgrade advice was for trac@… ;)
I never could reproduce that bug, I only saw it here on t.e.o when it was still using SQLite.
This issue was about a "database is locked" raised by a commit, and seeing that this commit apparently succeeded despite of this exception. I also never got replies on the pysqlite mailing list about this problem, so I think we end up with a wontfix here.
comment:6 by , 18 years ago
Keywords: | weird added |
---|---|
Milestone: | → none |
Priority: | low → normal |
Resolution: | wontfix |
Status: | closed → reopened |
Apparently, this still happens: http://pacopablo.com/irclogs/2007/03/05#T13:53:11 (more details needed)
This could be explained if the connection would be in autocommit mode (isolation_level==None
), which should normally not be the case (isolation_mode is ''
by default, which means use DEFERRED transactions).
comment:7 by , 18 years ago
Under DEFERRED transaction, If you direct write to the database with multithread, "database is locked" will jump out, Uf you do and read action and required shared lock, this will be ok, I don't know is this a correct reaction for sqlite :<
comment:8 by , 15 years ago
Component: | general → database backend |
---|
comment:9 by , 4 years ago
Milestone: | not applicable |
---|---|
Resolution: | → worksforme |
Status: | reopened → closed |
Interested in this ticket as well.