Richard Klein wrote:
John Stanton wrote:
Richard Klein wrote:
Joe Wilson wrote:
You've probably read this. It's useful information for any performance
minded developer using SQLite:
http://developer.mozilla.org/en/docs/Storage:Performance
>> [snip]
If the above is correct, it is not enough for the server thread to open
connections on behalf of client threads: The server must also open its
own connection, do a BEGIN TRANSACTION, create a dummy table containing
a single element, and then keep this dummy transaction open by *not*
doing a COMMIT.
Is this really true? I don't remember seeing this sort of dummy
transaction code in the src/test_server.c file.
I looked through the test_server.c program and it is clearly a
diagnostic rather than production program. I suspect that the reason
a transaction needs to be kept open is that Sqlite flushes all the
cache rather than writing through it to clear dirty pages, but I don't
understand the code enough to be sure.
According to the Mozilla article referenced above, it's even worse than
that: *All* cache pages, dirty or not, are freed at the end of *every*
transaction, even if the transaction consisted of only read operations.
If this is true, then it seems that a shared cache would be useful only
in apps for which there are many concurrent transactions in progress.
In other words, unless your app exhibits a high degree of concurrency, a
shared cache doesn't buy you much.
- Richard
I suspect that you are correct, with the one exception that the shared
cache mode cuts back on memory usage by avoiding replicated caches.
I have coded up a test and shall perform some measurements. One other
option is to look at Sqlite's flush logic and make a change for shared
cache mode so that it writes through the cache to clean dirty pages.
Some time ago we built a product which was an embedded ISAM file manager
using much the same principles as Sqlite. We designed it to operate in
two modes, one like Sqlite where each connection had its own cache and
would write through the cache and detect a stale cache and refresh (for
older non-POSIX OS's) it and the other mode mapped the file into VM and
used the virtual memory as its shared cache. The second mode runs very
fast, but is inherently not ACID because it generally is associated with
some form of lazy write.
In the ISAM case the data was not held in the B-tree like Sqlite and
could be independently sync'd to disk and a damaged index recreated from
the data to recover from a disaster. That approach has proven to be
robust and productive over many years of fairly large scale usage.
Perhaps there is a case for an Sqlitesuperlite stripped back for small
scale embedded use and an Sqmediumlite for shared usage. The "medium"
implementation would retain the endearing features of simplicity of use
but also be optimized towards multiple users.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
