Ken, Igor, I read the article you referenced. Much appreciated. http://sqlite.org/lockingv3.html
I didn't want to complicate my original questions with the intricate details of the application requirements which involve not allowing any database access while certain other operations are executing. I think a MUTEX, even with its inherent performance limitations, is the best solution. Thanks for your replies, Lee Crain P.S. Ken, I'm pretty certain that a MUTEX is both an intra- and inter-process mutual exclusion object. ________________________ -----Original Message----- From: Ken [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 2:22 PM To: sqlite-users@sqlite.org Subject: RE: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process If you are using seperate processes then a mutex will not help since it is local to a process. A semaphore could be used however. You can use a begin immediate around all statements that perform DML (ins/upd/sel) Then loop on the busy at the begin immediate command. This is a fairly simple thing to do. Then for selects you'll need only test the prepare/ and first step After the first step you should not get a sqlite busy. Lee Crain <[EMAIL PROTECTED]> wrote: Igor, I did say "controlled" concurrency. I'll rephrase question 3. 3) Would use of a MUTEX to avoid the dreaded "SQLite busy" condition be a good solution? Or is some other method of avoiding a busy condition recommended? Lee Crain __________________ -----Original Message----- From: Igor Tandetnik [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 1:36 PM To: SQLite Subject: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process Lee Crain wrote: > 1. Can multiple processes "concurrently" access the same SQLite > database? Yes. > 2. If so, can multiple processes maintain an open connection to the > database? Or must the connection be opened and closed, before and > after, > respectively, each database access? You can have multiple open connections, from the same or different processes, at any given time. You can keep a connection open as long as necessary. > 3. Would the use of a MUTEX as access protection be adequate to > successfully implement controlled "concurrency"? I'm not sure I understand this question. Mutexes are all about _not_ allowing concurrency. Igor Tandetnik -------------------------------------------------------------------------- --- To unsubscribe, send email to [EMAIL PROTECTED] -------------------------------------------------------------------------- --- -------------------------------------------------------------------------- --- To unsubscribe, send email to [EMAIL PROTECTED] -------------------------------------------------------------------------- --- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
