RE: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process
PTHREAD_PROCESS_SHARED mutex type for system-wide scope is equivalent to the USYNC_PROCESS flag to mutex_init() in the Solaris API (see below). The object initialized with this attribute must be allocated in memory shared between processes, either in System V shared memory (see shmop(2)). or in memory mapped to a file (see mmap(2)). It is illegal to initialize the object this way and to not allocate it in such shared memory. You are indeed correct, I however, contend that if you have to write code to create shared process memory just to allocate a process wide mutex. Then a semaphor would be simpler. So in general a mutex is not process capable. Its only when its created in shared memory that its can be made process wide. Thanks for raising this point. I've learned something new. Regards, Ken James Dennett <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 1: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. Many (maybe even most) platforms support mutexes which work across multiple processes. (Mutex is, of course, short for "mutual exclusion semaphore"; there's no a priori reason to assume that mutexes are process-local while other semaphores are not.) -- James - To unsubscribe, send email to [EMAIL PROTECTED] - James Dennett <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 1: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. Many (maybe even most) platforms support mutexes which work across multiple processes. (Mutex is, of course, short for "mutual exclusion semaphore"; there's no a priori reason to assume that mutexes are process-local while other semaphores are not.) -- James - To unsubscribe, send email to [EMAIL PROTECTED] - James Dennett <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 1: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. Many (maybe even most) platforms support mutexes which work across multiple processes. (Mutex is, of course, short for "mutual exclusion semaphore"; there's no a priori reason to assume that mutexes are process-local while other semaphores are not.) -- James - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process
> -Original Message- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 1: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. Many (maybe even most) platforms support mutexes which work across multiple processes. (Mutex is, of course, short for "mutual exclusion semaphore"; there's no a priori reason to assume that mutexes are process-local while other semaphores are not.) -- James - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process
Here's a bit more locking info that I found useful to help understand it all out of the archives: http://www.mail-archive.com/sqlite-users@sqlite.org/msg02845.html If you are writing a Windows app, you can use a named mutex which can be shared across processes. I have need for a blocking (as opposed to SQLITE_BUSY) mechanism as well. As the referenced thread points out, it is not straightforward. Still working something out... Lee Crain wrote: 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] -
RE: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process
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] -
RE: [sqlite] Re: Some Questions Regarding Access To a SQLite Database By More Than One Process
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 <[EMAIL PROTECTED]> 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] -
