PS>
  >                              If 4 nodes wishes to read/write to the same
  > message/file-base (thus, the same file), how do I coordinate this?
PS>

Three options :

  1.  Use an existing messagebase API, such as MSGAPI (i.e.  MSGAPI.DLL:
      a library of access routines for Squish messagebases), which will
      have the appropriate interlocks already implemented.  Of course, you
      will have to suffer the disadvantages and problems with whatever API
      and thus messagebase format you choose.  Squishbases, for example,
      have a limitation on the number of replies that a message can have.

      Of course, you aren't limited to "regular" messagebase formats.  One
      interesting scheme (probably only affordable by a commercial
      venture, I suspect) would be to implement your messagebase as a
      "real" database and access it using SQL.  Not only do you have the
      advantage of a proper relational database, but many of the database
      administration tools that you would otherwise have to write yourself
      would come as standard with the SQL engine.

  2.  Implement your own messagebase and access routines, and work out
      your own interlock scheme, using DosSetFileLocks for locking
      portions of the messagebase file(s).  You will have to read some
      textbooks about concurrent systems.

      Note that you must not roll your own API for someone else's
      messagebase.  It's not that it is impossible, it is more that you
      would have to exactly mimic the semantics of the existing API, lest
      your users come along with third-party tools that use the "official"
      API and screw up their messagebases because the locking protocols
      don't work with one another.

  3.  Design your messagebase access protocols so that file interlocking
      is not necessary, or at least drastically reduced.  For example, if
      you use one-message-per-file messagebases, then you can overcome
      many of the "atomic update" problems that exist in
"single-file"
      messagebases by using the semantics of the filesystem itself.

      For example, preventing a message from being read by other processes
      until it has been fully created is a simple matter of creating the
      message in a private temporary file, and using DosMove to move the
      file to the correct place once the file has been completely written.

      Note that many of the touted advantages of single file messagebases
      are in fact workarounds for the shortcomings of the FAT file system.
      With HPFS, many of them go away and one-message-per-file
      messagebases start to look attractive once again because of their
      advantages when it comes to atomicity.

      For example, many "single-file" messagebase formats claim that they
      avoid the large cluster size problems of FAT.  However, this isn't a
      problem with HPFS, where files are allocated space in units of 512
      bytes, irrespective of the partition size.

      Another touted advantage of single file messagebase formats is the
      problem of large directories.  Many message files in one directory
      can slow down operations quite significantly on FAT.  Again, though,
      this is a limitation of the filesystem, which HPFS doesn't suffer
      (HPFS doesn't store filenames linearly in directories), and so a
      one-message-per-file messagebase wouldn't suffer the problem on HPFS.

      Not that you have to _mandate_ HPFS for your program.  You could use
      8.3 filenames and have your messagebase work on FAT or HPFS.  All
      that you need to do is to stress to your users in their
      documentation that your messagebase will be more efficient on HPFS
      than it will be on FAT.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01