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
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
