Re: [sqlite] File locking additions

[drh]

"mohsen ahmadian" <[EMAIL PROTECTED]> wrote:
> hello All
>  the sqlite cant lock db for security data base if i have  a DB and must be
> close from Other program and cant Open this DB ,this DBMS not protect DB by
> User name and password
> i think a sqlite must be have 
> Mohsen Ahmadian

http://www.hwaci.com/sw/sqlite/prosupport.html#crypto

--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] File locking additions

[John Stanton]

You have discovered sqLITE.  For the features you need, go to an 
sqlHEAVY such as Oracle, DB2 or PostgreSQL.


mohsen ahmadian wrote:

hello All
 the sqlite cant lock db for security data base if i have  a DB and must be
close from Other program and cant Open this DB ,this DBMS not protect DB by
User name and password
i think a sqlite must be have 
Mohsen Ahmadian

Re: [sqlite] File locking additions

[mohsen ahmadian]

hello All
 the sqlite cant lock db for security data base if i have  a DB and must be
close from Other program and cant Open this DB ,this DBMS not protect DB by
User name and password
i think a sqlite must be have 
Mohsen Ahmadian

RE: [sqlite] File locking additions

[CARTER-HITCHIN, David, FM]

Hi,

> I definitely like all the things you've proposed. We currently use  
> SQLite over NFS (to a NetApp) and while it mostly works, we do  
> occasionally get locking issues that I'd love to be able to 
> get rid of.

Do you run Solaris or Linux?

Cheers,

David Carter-Hitchin.
--
Royal Bank of Scotland
Interest Rate Derivatives IT
135 Bishopsgate
LONDON EC2M 3TP

Tel: +44 (0) 207 085 1088



***
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered 
Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorized and regulated by the Financial Services Authority 
 
This e-mail message is confidential and for use by the 
addressee only. If the message is received by anyone other 
than the addressee, please return the message to the sender 
by replying to it and then delete the message from your 
computer. Internet e-mails are not necessarily secure. The 
Royal Bank of Scotland plc does not accept responsibility for 
changes made to this message after it was sent. 

Whilst all reasonable care has been taken to avoid the 
transmission of viruses, it is the responsibility of the recipient to 
ensure that the onward transmission, opening or use of this 
message and any attachments will not adversely affect its 
systems or data. No responsibility is accepted by The Royal 
Bank of Scotland plc in this regard and the recipient should carry 
out such virus and other checks as it considers appropriate. 
Visit our websites at: 
http://www.rbos.com
http://www.rbsmarkets.com 

Re: [sqlite] File locking additions

[Matt Sergeant]

On 7-Mar-06, at 7:06 PM, Adam Swift wrote:

In order to provide locking support for database files mounted from  
remote file systems (NFS, SMB, AFP, etc) as well as provide  
compatible locking support between database clients both local and  
remote, I would like to propose some additions to the existing  
database file locking behavior.


I definitely like all the things you've proposed. We currently use  
SQLite over NFS (to a NetApp) and while it mostly works, we do  
occasionally get locking issues that I'd love to be able to get rid of.


To those who have said "create a server" this simply isn't possible  
on an appliance NFS server.


URIs will allow us to do something like ?mkdir=1 to specify that if  
the directory didn't exist to make it first. Very handy.


Matt.

Re: [sqlite] File locking additions

[Helmut Tschemernjak]

[EMAIL PROTECTED] wrote:

Helmut Tschemernjak <[EMAIL PROTECTED]> wrote:
 
The current lock offset will not allow to copy open DB files if the 
database gets larger than 0x4000 bytes. This is because locked 
regions cannot be copied under Windows, we changed it to:


#define PENDING_BYTE  I64CONST(0x7fff)
#define RESERVED_BYTE I64CONST(0x7fff0001)
#define SHARED_FIRST  I64CONST(0x7fff0002)



You are, of course, free to changes SQLite in any way you want
for your own use.  But this change cannot be made in the official
SQLite implementation for two reasons:  (1)  It would break
backwards compatibility.  (2) It will not work on systems that
do not support large files (file bigger than 2GiB) such as many
old Unix implementations and Win95.

--
D. Richard Hipp   <[EMAIL PROTECTED]>




Every main desktop and server platform supports 64bit file offsets for 
minimum 5 years and many already for 10 years. If we get a common 
locking code which is cross platform network compatible (SMB, AFP, NFS) 
as well supporting all major existing OS by default is a good goal and 
will introduce incompatibilities anyways.


Custom solutions, embedded OS's, etc. must port the file IO, locking and 
threading anyways to their OS/solution.


Helmut Tschemernjak

Re: [sqlite] File locking additions

[drh]

Christian Smith <[EMAIL PROTECTED]> wrote:
> >
> >3. Extend the sqlite3_open commands to support URI style path
> >references in order to specify the file system locking type (as
> >opposed to modifying the arguments list).  After a little poking
> >around on RFC 3986  I'm inclined
> >to specify the locking choice via the query part of the URI.  For
> >example:
> >
> > file:///mounts/myhost/dbfile.db?locktype=flock
> > file:///localdisk/otherdbfile.db?locktype=automatic
> 
> 
> I'd be more inclined to add a PRAGMA. URIs are ugly and a pain to type in,

The reason for using a URI is so that you could specify
the locking style for databases that you ATTACH.  You are
not required to use a URI - an ordinary filename will continue
to work.  You could, perhaps, set the default locking mechanism
using a pragma.  But it is important to be able to specify
alternative locking mechanisms for ATTACHed databases.
--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] File locking additions

[drh]

Helmut Tschemernjak <[EMAIL PROTECTED]> wrote:
 
> The current lock offset will not allow to copy open DB files if the 
> database gets larger than 0x4000 bytes. This is because locked 
> regions cannot be copied under Windows, we changed it to:
> 
> #define PENDING_BYTE  I64CONST(0x7fff)
> #define RESERVED_BYTE I64CONST(0x7fff0001)
> #define SHARED_FIRST  I64CONST(0x7fff0002)
> 

You are, of course, free to changes SQLite in any way you want
for your own use.  But this change cannot be made in the official
SQLite implementation for two reasons:  (1)  It would break
backwards compatibility.  (2) It will not work on systems that
do not support large files (file bigger than 2GiB) such as many
old Unix implementations and Win95.

--
D. Richard Hipp   <[EMAIL PROTECTED]>

Re: [sqlite] File locking additions

[Adam Swift]

On Mar 8, 2006, at 8:01 AM, Helmut Tschemernjak wrote:



Hello Adam, all,

Cross platform locking is defiantly very important. The goal should  
be to use the identical sqlite DB via UNIX, AFP, SMB, NFS and  
others. My opinion is that it is not needed to have any additional  
open parameters, just use the locking features which are in common  
between all platforms.


Using an additional TCP/IP server is more complex in term of cross  
platform compatibility and may be an overkill in terms of  
performance, and will introduce additional problems.


At present the os_unix.c has some problems, I don't recall all its  
details so here is just an estimate:


Multiple locks are getting unlocked with one call
- This does not work on AFP and SMB

A Read lock gets turned into a writer lock (and or back?)
- This does not work on AFP, SMB has limited support for it.

The current lock offset will not allow to copy open DB files if the  
database gets larger than 0x4000 bytes. This is because locked  
regions cannot be copied under Windows, we changed it to:


#define PENDING_BYTE  I64CONST(0x7fff)
#define RESERVED_BYTE I64CONST(0x7fff0001)
#define SHARED_FIRST  I64CONST(0x7fff0002)

Advisory versus mandatory record locking
AFP and SMB is doing mandatory locking which means other clients  
cannot read locked file areas, advisory locking means that we can  
ready any data therefore we must call lock first before reading bytes.


The benefit of supporting the OS based locking is that after a  
program exits it will automatically cleanup all locks. Windows has  
some "oplock" features which will handle remote locks completely on  
the Windows SMB clients as long as only one writer uses the file.


It should not be this difficult to use only locking features which  
are in common cross major platforms and network file systems.




That's basically the goal, but instead of simply making '.lock' files  
the only locking mechanism (the only type of locks that work for some  
variants of NFS - thus the only locking features which are in common  
across major platforms and network file systems), we want to allow  
the developer to make the decision about the 'lowest common  
denominator' locking for the environment their database will be used in.


- adam

Re: [sqlite] File locking additions

[Adam Swift]

On Mar 8, 2006, at 12:27 AM, Manfred Bergmann wrote:


Hi.

You guys already distribute a SQLite version with locking support  
for remote databases with Mac OSX.

What would be the difference to that mechanism?


This would allow for manual configuration of the locking type to be  
used.  Currently on Mac OS X Tiger, the type of locking is  
automatically chosen to be the 'best available' based on the file  
system type & locking support features.



To have this in the original SQLite would be great.


Absolutely.

- adam

[sqlite] Re: semicolon in string (was Re: [sqlite] File locking additions)

[Nathaniel Smith]

On Thu, Mar 09, 2006 at 10:00:50AM +0200, Roger wrote:
> Hello guys.
> 
> I have a small problem.I am trying to write some sql queries. Whenever i
> put a semicolon, sqlite returns an error immediately.for instance if i
> select as follows
> 
> Select Name||" "||Surname||" ; "||Address as "Details
> >From Person
> where PersID=1098

What interface are you using to access sqlite?

If I put a semicolon in a string from the sqlite3 command line client
it works fine... e.g.:

sqlite> select ';';
;
sqlite> select ";";
;

but I could easily imagine a poorly written library
getting confused by such a thing.

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould

RE: [sqlite] File locking additions

[Chethana, Rao \(IE10\)]

Hello!

Why do u need semicolon there?
U can just give--   Select Name,Surname,' ',Address as Details from
personm where persID = 1098

Think this works.


-Original Message-
From: Roger [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 09, 2006 12:01 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] File locking additions

Hello guys.

I have a small problem.I am trying to write some sql queries. Whenever i
put a semicolon, sqlite returns an error immediately.for instance if i
select as follows

Select Name||" "||Surname||" ; "||Address as "Details
>From Person
where PersID=1098

Re: [sqlite] File locking additions

[Roger]

Hello guys.

I have a small problem.I am trying to write some sql queries. Whenever i
put a semicolon, sqlite returns an error immediately.for instance if i
select as follows

Select Name||" "||Surname||" ; "||Address as "Details
>From Person
where PersID=1098

RE: [sqlite] File locking additions

[Marian Olteanu]

I fully agree with you. This would be an external tool. But I underlined
that building such a tool is not a big enterprise. It can be done by a good
programmer in a reasonable amount of time.

Also, I would say that perfect sync over network file systems done by sqlite
is out of sqlite's scope. Especially if this would involve custom sync
mechanisms designed for each file system.

-Original Message-
From: Jay Sprenkle [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 08, 2006 8:18 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] File locking additions

On 3/7/06, Marian Olteanu <[EMAIL PROTECTED]> wrote:
> I would say that the best way to access a sqlite database mounted from a
> remote file server, concurrently with other processes is through a
database
> server. My opinion is that the overhead of file sync and file locking for
a
> remote file system is higher than simple TCP/IP communication overhead.
The
> server would be able to use also the same cache, would have very fast
access
> to the file (local file), etc.
>
> Building a server for sqlite is not a very complicated task. It can take
as
> few as a couple hours.

I'd like to see this option built as a separate project from sqlite.
Sqlite is a great tool when you don't need a server, and I'd hate to lose
that.
Let's add more tools to our toolset instead of just morphing one into
whatever is needed at the moment.

Re: [sqlite] File locking additions

[John Stanton]

We use the server approach, with a simple daemon on the remote machine 
which delivers its result in XML in accordance with the schema.  It 
works well.


Marian Olteanu wrote:

I would say that the best way to access a sqlite database mounted from a
remote file server, concurrently with other processes is through a database
server. My opinion is that the overhead of file sync and file locking for a
remote file system is higher than simple TCP/IP communication overhead. The
server would be able to use also the same cache, would have very fast access
to the file (local file), etc.

Building a server for sqlite is not a very complicated task. It can take as
few as a couple hours.


-Original Message-
From: Adam Swift [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 07, 2006 6:07 PM

To: sqlite-users@sqlite.org
Subject: [sqlite] File locking additions

All,

In order to provide locking support for database files mounted from  
remote file systems (NFS, SMB, AFP, etc) as well as provide  
compatible locking support between database clients both local and  
remote, I would like to propose some additions to the existing  
database file locking behavior.


I have discussed this briefly with D. Richard Hipp and he has  
expressed interest in pursuing it.  We would appreciate feedback/ 
suggestions/concerns on the proposed solutions below.


1. Support a variety of locking mechanisms, from the lowest  
granularity (using a .lock file)  to the highest (the  
existing advisory locks).  A preliminary list: .lock files, flock,  
afp locks, posix advisory locks.


2. Allow clients to specify type of locking (on database open)  
manually or ask sqlite to automatically detect the best locking  
supported by the file system hosting the database file (automatic  
detection would not work in a mixed local/remote file system  
situation, all clients of a single database file need to use the same  
type of locking to avoid conflicts).


3. Extend the sqlite3_open commands to support URI style path  
references in order to specify the file system locking type (as  
opposed to modifying the arguments list).  After a little poking  
around on RFC 3986  I'm inclined  
to specify the locking choice via the query part of the URI.  For  
example:


file:///mounts/myhost/dbfile.db?locktype=flock
file:///localdisk/otherdbfile.db?locktype=automatic

Thanks in advance for your input.

Adam Swift

Re: [sqlite] File locking additions

[Christian Smith]

On Tue, 7 Mar 2006, Adam Swift wrote:

>All,
>
>In order to provide locking support for database files mounted from
>remote file systems (NFS, SMB, AFP, etc) as well as provide
>compatible locking support between database clients both local and
>remote, I would like to propose some additions to the existing
>database file locking behavior.


Would be useful, especially for the Mozilla work.


>
>I have discussed this briefly with D. Richard Hipp and he has
>expressed interest in pursuing it.  We would appreciate feedback/
>suggestions/concerns on the proposed solutions below.
>
>1. Support a variety of locking mechanisms, from the lowest
>granularity (using a .lock file)  to the highest (the
>existing advisory locks).  A preliminary list: .lock files, flock,
>afp locks, posix advisory locks.


Why not start with just .lock and the existing locks? MacOS provides posix
advisory locks, I assume?


>
>2. Allow clients to specify type of locking (on database open)
>manually or ask sqlite to automatically detect the best locking
>supported by the file system hosting the database file (automatic
>detection would not work in a mixed local/remote file system
>situation, all clients of a single database file need to use the same
>type of locking to avoid conflicts).


So long as the better locking recognises the more primitive .lock files,
this should be workable. The use of .lock files is easy to test for at
database open time.

>
>3. Extend the sqlite3_open commands to support URI style path
>references in order to specify the file system locking type (as
>opposed to modifying the arguments list).  After a little poking
>around on RFC 3986  I'm inclined
>to specify the locking choice via the query part of the URI.  For
>example:
>
>   file:///mounts/myhost/dbfile.db?locktype=flock
>   file:///localdisk/otherdbfile.db?locktype=automatic


I'd be more inclined to add a PRAGMA. URIs are ugly and a pain to type in,
epsecially if you're lazy and rely on filename completion. Of course, I
assume the non-URI form would still work, but a PRAGMA still makes more
sense to me (and can be queried without parsing the URI.)

Perhaps multiple .lock files could be used to implement read/write locks.
Locks files of the form ".rd.lock." would be individual read
locks, which would be all hard links to the same ".rd.lock"
file, and the file reference count would be the read lock count.

A reserved lock would be indicated by the presence of both the
".rd.lock" and ".wr.lock" files, and once the last
reader has finished, the ".rd.lock" file is removed and the lock
is promoted to exclusive.

Such use of read/write lock files might slow the library down, though, as
directory operations are generally synchronous.


>
>Thanks in advance for your input.
>
>Adam Swift
>

Christian


-- 
/"\
\ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
 X   - AGAINST MS ATTACHMENTS
/ \

Re: [sqlite] File locking additions

[Helmut Tschemernjak]

Hello Adam, all,

Cross platform locking is defiantly very important. The goal should be 
to use the identical sqlite DB via UNIX, AFP, SMB, NFS and others. My 
opinion is that it is not needed to have any additional open parameters, 
just use the locking features which are in common between all platforms.


Using an additional TCP/IP server is more complex in term of cross 
platform compatibility and may be an overkill in terms of performance, 
and will introduce additional problems.


At present the os_unix.c has some problems, I don't recall all its 
details so here is just an estimate:


Multiple locks are getting unlocked with one call
- This does not work on AFP and SMB

A Read lock gets turned into a writer lock (and or back?)
- This does not work on AFP, SMB has limited support for it.

The current lock offset will not allow to copy open DB files if the 
database gets larger than 0x4000 bytes. This is because locked 
regions cannot be copied under Windows, we changed it to:


#define PENDING_BYTE  I64CONST(0x7fff)
#define RESERVED_BYTE I64CONST(0x7fff0001)
#define SHARED_FIRST  I64CONST(0x7fff0002)

Advisory versus mandatory record locking
AFP and SMB is doing mandatory locking which means other clients cannot 
read locked file areas, advisory locking means that we can ready any 
data therefore we must call lock first before reading bytes.


The benefit of supporting the OS based locking is that after a program 
exits it will automatically cleanup all locks. Windows has some "oplock" 
features which will handle remote locks completely on the Windows SMB 
clients as long as only one writer uses the file.


It should not be this difficult to use only locking features which are 
in common cross major platforms and network file systems.



Helmut Tschemernjak

Adam Swift wrote:

All,

In order to provide locking support for database files mounted from 
remote file systems (NFS, SMB, AFP, etc) as well as provide compatible 
locking support between database clients both local and remote, I would 
like to propose some additions to the existing database file locking 
behavior.


I have discussed this briefly with D. Richard Hipp and he has expressed 
interest in pursuing it.  We would appreciate 
feedback/suggestions/concerns on the proposed solutions below.


1. Support a variety of locking mechanisms, from the lowest granularity 
(using a .lock file)  to the highest (the existing 
advisory locks).  A preliminary list: .lock files, flock, afp locks, 
posix advisory locks.


2. Allow clients to specify type of locking (on database open) manually 
or ask sqlite to automatically detect the best locking supported by the 
file system hosting the database file (automatic detection would not 
work in a mixed local/remote file system situation, all clients of a 
single database file need to use the same type of locking to avoid 
conflicts).


3. Extend the sqlite3_open commands to support URI style path references 
in order to specify the file system locking type (as opposed to 
modifying the arguments list).  After a little poking around on RFC 3986 
 I'm inclined to specify the 
locking choice via the query part of the URI.  For example:


file:///mounts/myhost/dbfile.db?locktype=flock
file:///localdisk/otherdbfile.db?locktype=automatic

Thanks in advance for your input.

Adam Swift

Re: [sqlite] File locking additions

[Jay Sprenkle]

On 3/7/06, Marian Olteanu <[EMAIL PROTECTED]> wrote:
> I would say that the best way to access a sqlite database mounted from a
> remote file server, concurrently with other processes is through a database
> server. My opinion is that the overhead of file sync and file locking for a
> remote file system is higher than simple TCP/IP communication overhead. The
> server would be able to use also the same cache, would have very fast access
> to the file (local file), etc.
>
> Building a server for sqlite is not a very complicated task. It can take as
> few as a couple hours.

I'd like to see this option built as a separate project from sqlite.
Sqlite is a great tool when you don't need a server, and I'd hate to lose that.
Let's add more tools to our toolset instead of just morphing one into
whatever is needed at the moment.

Re: [sqlite] File locking additions

[Manfred Bergmann]

Hi.

You guys already distribute a SQLite version with locking support for  
remote databases with Mac OSX.

What would be the difference to that mechanism?
To have this in the original SQLite would be great.


Best regards,
Manfred


Am 08.03.2006 um 11:06 schrieb Adam Swift:


All,

In order to provide locking support for database files mounted from  
remote file systems (NFS, SMB, AFP, etc) as well as provide  
compatible locking support between database clients both local and  
remote, I would like to propose some additions to the existing  
database file locking behavior.


I have discussed this briefly with D. Richard Hipp and he has  
expressed interest in pursuing it.  We would appreciate feedback/ 
suggestions/concerns on the proposed solutions below.


1. Support a variety of locking mechanisms, from the lowest  
granularity (using a .lock file)  to the highest  
(the existing advisory locks).  A preliminary list: .lock files,  
flock, afp locks, posix advisory locks.


2. Allow clients to specify type of locking (on database open)  
manually or ask sqlite to automatically detect the best locking  
supported by the file system hosting the database file (automatic  
detection would not work in a mixed local/remote file system  
situation, all clients of a single database file need to use the  
same type of locking to avoid conflicts).


3. Extend the sqlite3_open commands to support URI style path  
references in order to specify the file system locking type (as  
opposed to modifying the arguments list).  After a little poking  
around on RFC 3986  I'm  
inclined to specify the locking choice via the query part of the  
URI.  For example:


file:///mounts/myhost/dbfile.db?locktype=flock
file:///localdisk/otherdbfile.db?locktype=automatic

Thanks in advance for your input.

Adam Swift









___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [sqlite] File locking additions

[Ritesh Kapoor]

In case the designer knows that the DB file will be accessed by a single
program-thread throught the run - then there should be some sort of flag
indicating that SQLITE should execute minimum locking-related code.

We were facing problems with flock over NFS mounted file systems.  Since
we din't need any locking on our DB file I copy-pasted the return
statement in function 'sqlite3OsLock' to the beginning of the function,
so that it always returns SQLITE_OK.

Regards,
ritesh


On Wed, 2006-03-08 at 05:36, Adam Swift wrote:
> All,
> 
> In order to provide locking support for database files mounted from  
> remote file systems (NFS, SMB, AFP, etc) as well as provide  
> compatible locking support between database clients both local and  
> remote, I would like to propose some additions to the existing  
> database file locking behavior.
> 
> I have discussed this briefly with D. Richard Hipp and he has  
> expressed interest in pursuing it.  We would appreciate feedback/ 
> suggestions/concerns on the proposed solutions below.
> 
> 1. Support a variety of locking mechanisms, from the lowest  
> granularity (using a .lock file)  to the highest (the  
> existing advisory locks).  A preliminary list: .lock files, flock,  
> afp locks, posix advisory locks.
> 
> 2. Allow clients to specify type of locking (on database open)  
> manually or ask sqlite to automatically detect the best locking  
> supported by the file system hosting the database file (automatic  
> detection would not work in a mixed local/remote file system  
> situation, all clients of a single database file need to use the same  
> type of locking to avoid conflicts).
> 
> 3. Extend the sqlite3_open commands to support URI style path  
> references in order to specify the file system locking type (as  
> opposed to modifying the arguments list).  After a little poking  
> around on RFC 3986  I'm inclined  
> to specify the locking choice via the query part of the URI.  For  
> example:
> 
>   file:///mounts/myhost/dbfile.db?locktype=flock
>   file:///localdisk/otherdbfile.db?locktype=automatic
> 
> Thanks in advance for your input.
> 
> Adam Swift
> 

RE: [sqlite] File locking additions

[Marian Olteanu]

I would say that the best way to access a sqlite database mounted from a
remote file server, concurrently with other processes is through a database
server. My opinion is that the overhead of file sync and file locking for a
remote file system is higher than simple TCP/IP communication overhead. The
server would be able to use also the same cache, would have very fast access
to the file (local file), etc.

Building a server for sqlite is not a very complicated task. It can take as
few as a couple hours.


-Original Message-
From: Adam Swift [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 07, 2006 6:07 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] File locking additions

All,

In order to provide locking support for database files mounted from  
remote file systems (NFS, SMB, AFP, etc) as well as provide  
compatible locking support between database clients both local and  
remote, I would like to propose some additions to the existing  
database file locking behavior.

I have discussed this briefly with D. Richard Hipp and he has  
expressed interest in pursuing it.  We would appreciate feedback/ 
suggestions/concerns on the proposed solutions below.

1. Support a variety of locking mechanisms, from the lowest  
granularity (using a .lock file)  to the highest (the  
existing advisory locks).  A preliminary list: .lock files, flock,  
afp locks, posix advisory locks.

2. Allow clients to specify type of locking (on database open)  
manually or ask sqlite to automatically detect the best locking  
supported by the file system hosting the database file (automatic  
detection would not work in a mixed local/remote file system  
situation, all clients of a single database file need to use the same  
type of locking to avoid conflicts).

3. Extend the sqlite3_open commands to support URI style path  
references in order to specify the file system locking type (as  
opposed to modifying the arguments list).  After a little poking  
around on RFC 3986  I'm inclined  
to specify the locking choice via the query part of the URI.  For  
example:

file:///mounts/myhost/dbfile.db?locktype=flock
file:///localdisk/otherdbfile.db?locktype=automatic

Thanks in advance for your input.

Adam Swift