Alec Thomas wrote:
On Sat, Mar 18, 2006 at 10:30:29AM -0500, Jean-Paul Calderone wrote:
This does not seem to be purely load-induced. Several times a week, our
trac instance gets into some kind of state where any request at all will
result in this error. We are using mod_python and do not have particularly
high load. The error happens on every request until apache is restarted.
Jean-Paul
I've also seen this on TracHacks a number of times:
[EMAIL PROTECTED]:/srv/trac-hacks/trac/log]grep 'is locked' * | wc -l
140
It is "nomal" or at least expected that the DB will be locked at times and
therefore that a few requests will end up with that error ('is locked').
This happens when there are two (or more) simultaneous attempts to write
in the DB: only one will succeed, and the other will fail.
However, what is _not_ normal is that the DB stays in a locked state and
that
a restart of the server is needed. This shouldn't happen anymore with
recent
pysqlite bindings (>= 2.0.5) and a SQLite library compiled with the
--enable-threadsafe configuration switch.
If this happens even if the above prerequisites are fulfilled, a new
ticket should
be created, with as much configuration detail as possible, so that we
could try
to reproduce the issue.
-- Christian
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
