So what you are saying is that opening a SQLite DB on a shared network
drive SHOULD work with multiple clients (if all servers and NFS-version
are updated to most recent version)?
Roger Binns wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jay Sprenkle wrote:
This sounds exactly like what
causes the trashed shared MS Access databases I've seen and network locking
issues I see warnings about here.
No it isn't.
How is this supposed to work correctly without the client being notified?
Err, the client OS is notified with an oplock break.
If I write an application that requires serialized access to a file, and
I rely
on operating system locking, if the operating system drops my locks
without notifying me my design breaks.
You are totally confused. The application talks to the client OS
(kernel). The abstraction is a kernel interface and file handles. The
kernel then has a provider for the relevant filesystem. That provider
then talks to a block layer or over the network. Oplocks etc are
happening in that second part. They are not application visible.
(1)Application <= (2)kernel => (3)redirector <= (4) network server
Oplocks are something available in the SMB protocol (and recent NFS
versions) between 3 and 4. They allow the redirector to optimize in the
case when it is the only client with the file open. For example if
oplocks are not available, then every read/write/lock request from the
application (1) gets to the redirector (3) which has to contact the
server (4) in order to satisfy the request.
If the server (4) grants an oplock to the redirector (3) then that
redirector knows it is the only client of the server with the file open.
Therefore file contents cannot change so it can cache file content
information. Similarly it can also do all byte range locking internally
since no other client has the file open.
If another client requests to open the file, then the server (4) sends
the oplock break to the first redirector which will discard cached file
contents and apply byte range locks it was handling internally, before
acknowledging the oplock break. From that point on it has to send all
read/write/lock requests to the server since the other client(s) could
be modifying the file.
At no point in all of this is the application(1) aware of oplocks, nor
does it have any control over them. Heck even the kernel (2) doesn't
know. It just hands all requests to the redirector (3) which can use
oplocks to optimize performance.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFpdWdmOOfHg372QQRArwkAKC+NX8C8KTBtL5DVKNZbefZ0W/VTACgi7Kr
JBlumHql+rsB0AbjG/5NNpM=
=YNJF
-----END PGP SIGNATURE-----
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
