Hello,

>> My understanding, after all of your helpful comments,  currently is:
>> 
>> Simultaneous reading of a server file by different clients is safe, as
>> long as the file doesnt get changed at all (at least in a time scale
>> where the Client Os could cache it).

Mrs.> Remove your parenthesized exception and this is correct.

My current plan is:

Store the (readonly) database on the server and include version info
in a table in the database. Each time the client app starts, it
accesses the server database and checks the version info. Based on
this it decides whether it needs to copy the database file locally
(the server version is newer or there is no local version) or can use
the current local version (the version of the server database is the
same as the local version).

Its possible that more than one client will be accessing this version
info simulataneously. Can there be any problem? Using sqlite to read
this version info via a SELECT should map cleanly to a read only
access to the disk file, right? This is the only point where imnot
fully sure. According to the above should then be fine?

The server database will need to be updated at some stage. The sys
admin will haye to be responsible for seeing that no client is
accessing the file while its being updated (by disconecting the server
from the network or doing the job at niight when all clients are off,
or just making sure that none are running my app or whtever). What
should I advise him is a necessary/reasonable procedure, and what are
the worst case scenarios for each appraoch?

As far as I can understand, the only thing that absolutely must be
ensured is that no app starts after the sys admin begins replacing the
file, and before he's finished, because then the client would
possibly get corrupt data. This could be ensured eg by
temporarily disconnecting the server from the network.

Given this worst that could happen (which is extremely unlikely, but not
completely impossible), due to client os caching, would be that
upon restarting the clients then dont know that the serever database
is newer, and dont copy it locally it, and instead continue to work with the
old data (local version).


Does this sound like a good approach?


>> The same applies to sqlite accesses since it just uses regular files.
>> And when you only querying the database (not changing the data), you
>> are just reading the database file .. ie sqlite doesnt do anything
>> which would break the clients only reading condition.
>> 
>> Am I right so far?

Mrs.> Almost.

Mrs.> You make a distinction between Client and Server and I don't
Mrs.> think you know who they are.

Whats that supposed to mean?

Mrs.> It's helpful to understand that the server cannot update files. Ever.
Mrs.> Only clients can update files. The server coordinates these updates. In
Mrs.> reality, in many cases, the server coordinates fine. In others, it fails
Mrs.> miserably.

You can work with the server just as a normal machine. It happens to
be functioning as a network server for clients on the network. Eg. the
system admin can copy a database file from a cd onto the harddisk of the
server. The server updates the database here, not the client.

>> The size of a file depends for example on the cluster size of the
>> underlying partition. And regardless is of little value in comparing
>> two files; the same file size/name doesnt mean two files are
>> identical.

Mrs.> The size of a file does not depend on the cluster size of the underlying
Mrs.> partition. That's how much SPACE the file takes up.

Mrs.> Whether or not your filesystem records the size of a file isn't
Mrs.> important.

It is. Its all that matters here.

Mrs.> The concept of file size exists, and it has nothing to do
Mrs.> with clusters or blocks or extents... almost all
Mrs.> filesystems...correct

One wants to reliably determine this invariant size and not the space
occupied on disk or some other measure reported which depends on cluster
size or whatever. "Almost" or "roughhly" is not reliable.

Mrs.> The test is not to determine whether or not the files are identical,

It is.

Mrs.> but if one has been changed. This method will certainly download
Mrs.> files when they haven't been changed (although it's unlikely).
Mrs.> This unusual case wastes some bandwidth. In contrast to
Mrs.> downloading it all the time, where you always waste bandwidth.

If you cant tell when files are identical, you cant tell when you dont
need to download, so you need to download always, so you needent bother
checking the filesize in the first place.

Mrs.> If you're looking for cross-platform you need to select protocols that
Mrs.> have well defined semantics. HTTP sounds like a good bet. Full file copy
Mrs.> sounds like a better one.

My app will access the files on the network (LAN) as if theyre local.


-- 
Best regards,
 djm                            mailto:[EMAIL PROTECTED]


Reply via email to