Re: Re: [iPAQ] GPE - GNU PDA Environment

On Sat, 29 Dec 2001 20:23:06 +0100
Nils Faerber <nils_at_kernelconcepts.de> wrote:
> On 29 Dec 2001 20:09:59 +0100
> Erik Bågfors <erik_at_bagfors.nu> wrote:
> > On Sat, 2001-12-29 at 20:04, Alan Cox wrote:
> [...]
> > > > addresslist. If I just add that to the other
> address-application's
> > > > database and that program is running it will not know that I added
> > it.
> > > SQL has extensions for this too
> > Really?? Does SQLite support this??
> Good point ;)
> Let's have a look at it!
OK, I just had a first look and the FAQ says the following:
------->
(6) Can multiple applications or multiple instances of the same
application access a single database file at the same time?

Multiple processes can have the same database open at the same time. On
unix systems, multiple processes can be doing a SELECT at the same time.
But only one process can be making changes to the database at once. On
windows, only a single process can be reading from the database at one
time since Win95/98/ME does not support reader/writer locks.
The locking mechanism used to control simultaneous access might not work
correctly if the database file is kept on an NFS filesystem. You should
avoid putting SQLite database files on NFS if multiple processes might try
to access the file at the same time.
Locking in SQLite is very course-grained. SQLite locks the entire
database. Big database servers (PostgreSQL, MySQL, Oracle, etc.) generally
have finer grained locking, such as locking on a single table or a single
row within a table. If you have a massively parallel database application,
you should consider using a big database server instead of SQLite.
When SQLite tries to access a file that is locked by another process, the
default behavior is to return SQLITE_BUSY. You can adjust this behavior
from C code using the sqlite_busy_handler() or sqlite_busy_timeout() API
functions. See the API documentation for details.
<-------

So we have at least a lock on writes; though this lock locks the whole
database and not only the affected table :(
I did also not find any reference to a "changed" handler, yet.

CU
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          D1 : +49-170-2729106
--