Ken wrote:
I guess my point was that inside the server thread, once a transaction is entered upon behalf of a client then only that activity may continue and no others. So in my design i only had two choices, re-enqueue the message inside the server until the transactional thread completed or return an error to the client. I preferred keeping the message on the queue waiting to be serviced. This is also programmaticaly a pain in the arse since you must guarantee the client doesn't abandon its responsibilities and exit without sending a close command into the server thread, resulting in a permanently blocked server queue.
Good point! I hadn't even thought of that additional responsibility of the server thread. As you say, the server could avoid this responsibility by simply returning an error to the client. One could even argue that this is not imposing too heavy a burden on the client, since in a traditional server-less architecture in which each client opens his own connection, the client must always be prepared to deal with a SQL_BUSY error return from SQLite. However, I like your choice better: If you're going to go to the trouble of having a server, you may as well go the extra mile and have the server make the client's life a little easier! Regards, - Richard
----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
