Strange `database is locked` error: commit fails but data is nevertheless saved...

[cboos]

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...

[anonymous]

Interested in this ticket as well.

[sid]

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?

[cboos]

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.

[trac@…]

using pysqlite3 gets rid of that issue.

[cboos]

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).

[anonymous]

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 :<