On 11/23/03 6:22 PM, D. Richard Hipp wrote:
Lots of people seem to think that better concurrency in SQLite would be useful. But I am having trouble understanding why.
I have SQLite or Server systems. I would like not to make that choice - soft option I mean. As you can read I'm useing "would". If the change means lost of too much - forget it. I'll stay with closeing transactions.
In simple way - large, compiled, selects.Please, give me some examples of the kinds of things you are doing which could benefit from improved concurrency.
* What SQL are you running that takes more than a fraction of a second to complete?
* Are you holding transactions open for an extended period of time? Why?
All the process operates in transaction - it can be changed... I'm going to close transactions after the cnage to unlock the file.
If shared file - up to 5.* How many processes do you have trying to access the database at once?
None, but handler is my choice.* How do you currently handle SQLITE_BUSY replies? Do you use the sqlite_busy_handler() or sqlite_busy_timeout() APIs?
* How large are your databases?If shared file - < 1MB.
* Do you ever put database files on a shared filesystem?I need it, as I wrote. Right now app works as desktop.
The better I understand the problems, the better job I will be able to do in resolving them. Thanks for you responses.
> Thank you for your time.
-- Regards, Michal Zaborowski (TeXXaS) http://sqlite4delphi.sourceforge.net/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
