Hello all
If I look at the "Locking And Concurrency"-Description from my
current Viewpoint, as a Viewpoint with present understandig, the
Description is ok.
If I remember to my Viewpoint in the past, without this present
understandig, before some very pleasant helppostings explain the
coherences, the Description stays imho a little bit behind a fog.
It is not closing clearly, in particular if a User migrate from
OLE-DB.
A simple list of facts like the following example at the end of the
existing Description would be amazing. I have read all postings
again and collect the important statements and aspects. If anyone
found this later in this list, i hope it is helpful to him.
Facts:
- SQLLite is not a Server-DBMS, but a Single-File-Database on your
Harddisk/Server-Filesystem.
- How many users can share a file? So much as needed. Sqlite can be
shared between users just like a word-processing file shared between
multiple users. It just uses the regular fcntl-type file locks.
- SQLite handles the Filelockings during its write to File as a
Filelocking based on the operating system, not based on the DB-Tables
and Records.
Remarks (MS, fcntl-Routines) The Locking-Function locks or unlocks
nbytes bytes of the file specified by fd.
Locking bytes in a file prevents access to those bytes by other
processes. All locking or unlocking begins at the current position of
the file pointer and proceeds for the next nbytes bytes. It is possible
to lock bytes past end of file.
- Sqlite does the needed filelocking automatically until the changes to
be written to file. During this Process prevent SQLite concurrent
access (Read and Write). That takes just as long until changes are
written succesful to file.
- Now, if there are multiple processes trying to update the same database
file, only one can update it at a given moment. Attempts to do updates,
or start a transaction will fail with an error indicating the database
is locked.
This applies even if the two processes are updating different tables.
That is in Contrast with a full database server (like SQL server, MySql,
etc.), which has grained locking, and can let two processes update
different tables, or even different rows on the same table, at the
same time.
- Provided you code handles the errors ((SQLITE_BUSY) by retrying the
update until it succeeds), it should work fine. However, if there are
lots of processes doing large updates to the same database file, they
may be waiting for each other a lot.
- A "logical" Recordlocking behalf a current Record/Row during a View or a
Edit, or behalf a current leading Record and his set of appended
Childrecords in other tables, is in the current version not
implemented and primary not supported. A Application have to do this
by itself.
Hopeful that my collection is correct... :-)
Greetings to all from Germany
Anne
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
