On the topic of a more efficient busy handler, one approach I considered was to implement an event which was signalled when a database unlock occurred. That way, the busy handler could just wait on the event (which is an efficient wait state), and be guaranteed of a wake up when the lock is released (the event would be signalled at this time.) However, I wasn't at the time familiar enough with SQLite's innards to implement such a beast. Can anyone see any pitfalls to such an approach?
Ian On 6/1/07, John Stanton <[EMAIL PROTECTED]> wrote:
Tom Briggs wrote: > > >>I don't want to use >>other database, because I think Sqlite is great for an >>embedded system that I >>am using. > > > I think that your own questions about concurrency prove this > incorrect. If you need high concurrency and you don't like retries, > SQLite is not the database for you. > > -T > If you require ACID type data integrity and have a single disk there is no such thing as a "high concurrency database". They all share a single disk resource in some way. With Sqlite it is up to the designer to build in concurrency and that cna be done by single streaming. Better performance is achieved by using a single database connection so that cache hits are maximized. If your design is such that you never get a busy then you have an effective allocation of your disk resource. Using mutexes between threads and semaphores between processes gives you that capability. To my mind the only time you should use the busy logic is when you are working across a network with shared files. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
