Large operations in sync databases

Andrew Sutherland asutherland at asutherland.org
Tue Jul 13 14:31:28 UTC 2010


  On 07/13/2010 05:11 AM, Ben Bucksch wrote:
> I take it sqlite is not multi-threaded? If it was, it should take care 
> of the problem. If it isn't, I am not sure two databases solve the 
> problem, as sqlite may still block even across databases. Have you 
> tried both variants?

The greater context is that rkent is implementing a new account type 
targeted at Thunderbird 3.1.  The need for anything to be synchronous is 
an outgrowth of the semantics of most Thunderbird message database 
operations executing synchronously on the main thread.  The choice of 
multiple databases is to eliminate the chance for a long-running 
operation off the main thread to acquire a lock that would block the 
main thread.  Also, to keep all database operations on the main thread 
predictably short so that even when disk seeks happen, there are few 
enough that interactive response is not greatly impacted.

To more explicitly answer the quoted section, SQLite has various 
mechanisms of support for multiple threads to access a single database, 
but the best-case situation finds locks operating on a table level of 
granularity, which, once acquired, are retained for the duration of the 
transaction.  ( http://www.sqlite.org/sharedcache.html).  There some 
other ways one can roll, but they also have similar worst-case behaviour.

Obviously, in the long run we want all Thunderbird activity (both core 
and extension-provided account types) to have all their I/O happen off 
the main thread and without storing everything in memory.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20100713/4e9392f6/attachment.html>


More information about the tb-planning mailing list