1. How many simultaneous users do you expect?
2. How many simultaneous "writers" (i.e.: users making changes, adding, and deleting records - as opposed to searching and examining results)
3. Which OSs are we dealing with?
4. Is there any allowable downtime?

Unlike a web server which uses temporary connections, Sesame requires a constant connection between the client and the server. That may well change in future versions. But in the meantine, you will also have to consider some kind of connection management, so when one server goes offline, the other can pick up the connections and attempt to restore context.

A Sesame application fileset can be copied out from under a Sesame server, and typically it is okay. It will be "locked", but in most cases a sunlock operation before redeployment will take care of that. The exception to this is during very lengthy write operations to the server wherein a lot of records are being changed in sequence or in parallel.

To avoid this your best recourse would be to suspend (do not kill) the Sesame server process. Sesame has only one process with multiple threads. When the main process is suspended the threads will suspend along with it. Unix has commands for doing this. I do not know whether any flavor of Windows will.

After the process is suspended the clients connected to the server will remain connected and context will be sustained. Timing is important. There are tools on both Windows and Unix to determine if Sesame (any process) has the files open. On Unix these can be automated using shell scripting. I have not seen any tools on Windows that can be automated (they have a GUI interface and do not return values to scripts).

Sesame only has the file open when actually writing. Even with many simultaneous writing users, the windows of opportunity should be very frequent and (by computer's perspective of time) lengthy.

On Unix, It may well be doable to create a shell script kicked off with cron at some interval that waits for a moment when Sesame does not have the files open, and then suspends Sesame, copies the files (use something like rsynch), re-enables Sesame - all within a few moments.

If there is sufficient demand, I can add a suspend command to the administration interface in Sesame 2.0.

Quote:

Because Sesame does not actually keep files open unless it is specifically writing to them, it does set a flag in the file indicating that that file is in use. Sunlock is a program that can clear that flag.
Quote:

Depends entirely on what they are doing. If they are in the middle of a lengthy non-interactive operation, you can probably go quite a while before that user notices. If another user is stepping through records, they will probably notice any slow down or stutter.
Quote:


As I mentioned, you will need to make sure that the file is not open by Sesame server before you attempt suspending the process.

Twenty some years on Unix, but I'm still not much for shell scripting. The general logic of the script would be:

Get the PID for Sesame with "pidof"
while not done and have not tried enough
  check if Sesame has files open (use lsof and grep, or fuser)
  if the files are not open
    suspend Sesame with "kill -s SIGSTOP sesame_pid"
    copy the .db and .dat
    re-enable Sesame with "kill -s SIGCONT sesame_pid"
    set done to true
  end if
end while
 

Quote:


Thank you very much.  I'm working on a script applying the logic above.  When I have it finished and working I'll post it.  It's good to hear that suspension will be in version 2.0. 

Looks good to me (also no expert on shell scripting). Is every 5 seconds a bit of overkill?