#3446: Rate of `database is locked` errors is too high
------------------------------------+---------------------------------------
Reporter: cboos | Owner: cboos
Type: defect | Status: new
Priority: normal | Milestone:
Component: general | Version: devel
Severity: major | Resolution:
Keywords: database lock pysqlite |
------------------------------------+---------------------------------------
Changes (by cboos):
* owner: jonas => cboos
Comment:
Well, despite r3616 we still have a high rate of "database is locked"
error.
See #3503 for a short-term solution (an nice !TracError explaining what
happens instead of a backtrace).
Long-term, I think we should do the following:
- '''Shorten our transactions'''. In particular, a main reason for the
problem seems to be the long periods of time during which SHARED locks are
held. The common programming idiom in Trac is to ''iterate'' over cursors,
performing some operation for each of the returned row. While this may
sounds a good approach which lowers memory consumption, it lengthens the
period during which a SHARED lock is held and during which ''not a single
write'' can be done. We should instead read everything in memory first,
''then'' process the data. Of course, if there are some very
straightforward tasks (like filtering) that can be done while reading the
data, it could still be done by iterating over the cursor.
- Also, if there are situations where not all the rows from a cursor are
fetched, the cursor should be closed, so that the SHARED lock can be
release as soon as possible.
- '''Repeatable transactions''': instead of doing writes into the
database as soon as we feel like doing so, we could pass a callback to the
database layer which will be used for writing all the information. The
advantage of this would be to be able to ''retry transparently'' the write
sequence if a `database is locked` exception is detected. This should
also play well with the journalling approach described in
TracDev/Proposals/Journaling.
--
Ticket URL: <http://trac.edgewall.org/ticket/3446#comment:4>
The Trac Project <http://trac.edgewall.com/>
_______________________________________________
Trac-Tickets mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-tickets
