My assumption for the server thread was that it needed to process all incoming
requests in transaction order and to not loose outstanding requests. You have
two choices once a client initiates a transaction:
a. reject the incoming request since a transaction is active in the
server. The client would then be able to re-submit the request... This seemed
to have alot of overhead since the client would then need to have code to
resubmit in the event of a Reject.
And then it would simply sit in a loop re-posting the message until it
got a valid acknowledgment...
b. re-Queue the request to the tail, causing the client to block
waiting for a response from the server. The active client will eventually
complete its transaction and the next in the queue will be serviced.
I favored option b. Since it caused less thrashing about when the client
intiated a read request or another transaction request when a transaction was
already in progress.
Hope that helps.
John Stanton <[EMAIL PROTECTED]> wrote: Ken wrote:
> Richard,
>
> You might want to look at src/test_server.c for an example of the
> shared_cache if you haven't found it already.
>
> Personally, I think it makes a lot of sense (read simpler) to implement
> independent connections than to implement a server. But I can see why you
> might want a server if you have many threads and memory constraints.
>
> The server still can only have one transaction running at a time, even though
> the cache is shared. However, it can run multiple select operations and
> perform dirty reads(when enabled).
>
> The biggest difficulty encountered with the server is how to handle client
> requests when a transaction was in progress... Do you re-queue or just fail
> and have the client resend? My solution was to keep a state of a client
> thread id when it started a transaction. If the server thread encountered a
> message that was not from the client thread that started the transaction it
> moved the message to the end of the queue.
>
Why not just block on the transaction?
>
> Your welcome to call email me directly if you need more info or call if you'd
> like to discuss my experiences with the server/thread approach.
>
> Regards,
> Ken
>
> Richard Klein wrote:
>
> Richard Klein wrote:
>
>>
>>[EMAIL PROTECTED] wrote:
>>
>>>John Stanton 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
>>>
>>
>>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
>>
>
>
> Upon further reflection, I realized that the scheme outlined above
> won't work.
>
> The problem can be summed up on one word: TRANSACTIONS. There needs
> to be a way to make sure that the SQL statements composing a trans-
> action in client thread 'A' aren't intermixed with those composing a
> transaction in client thread 'B'.
>
> The SQLite connection is the structure designed to keep track of state
> information such as whether or not a transaction is in progress. If
> client threads 'A' and 'B' share the same connection, then the burden
> of maintaining this state information falls on the server thread. Not
> a great idea.
>
> Therefore, it would appear that I have two options:
>
> (1) Have the server thread open separate connections for client threads
> 'A' and 'B', and enable shared cache mode so that the two connections
> can share cached items. This option requires upgrading to SQLite version
> 3.3.0 or higher.
>
> (2) Abandon the idea of a server thread; have threads 'A' and 'B' open
> their own connections and access SQLite directly. This option does *not*
> allow the sharing of cached items, but allows me to stay with SQLite
> version 2.8.17.
>
> - Richard
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
