[EMAIL PROTECTED] wrote:
John Stanton <[EMAIL PROTECTED]> wrote:
Yes, each connection has a cache. A lot of concurrent connections means
a lot of memory allocated to cache and potentially a lot of duplicated
cached items. See shared cache mode for relief.
Yes. But remember that shared cache mode has limitations:
* When shared cache mode is enabled, you cannot use
a connection in a thread other than the thread in which
it was originally created.
* Only connections opened in the same thread share a cache.
The shared cache mode is designed for building a "server thread"
that accepts connection requests and SQL statements via messages
from "client threads", acts upon those requests, and returns the
result.
--
D. Richard Hipp <[EMAIL PROTECTED]>
I suppose that I could accomplish almost the same thing in 2.8.17,
even though shared cache mode is not available in that version.
I could have a server thread that opens the database, and then
accepts and processes SQL statements via messages from client
threads.
The only difference would be that the client threads could not
send connection requests. There would be only one connection,
and it would be opened implicitly by the server thread at system
startup.
The benefit would be that all the client threads would effectively
share the same cache, since there would in fact be only one connection.
The cost would be that each SQL statement would require an additional
two context switches to execute.
In my application (TiVo-like Personal Video Recorder functionality
in a set-top box), the benefit of memory savings far outweighs the
cost of a performance hit due to extra context switches.
- Richard
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
