Opening of a stack on a shared drive (how to lock out)

[stecxjo]

I created a game board app for a group of teachers to use with their students in a classroom social studies game. Works fine. But the teachers have asked if they could allow another group of teachers and students to join in on the game and then use the app to record both "teams."

I don't want to code for simultaneous use with this. No need for it. It's just a static board to record what happens in the classrooms with the "game". I'd like to be able to lock out the app if one group is currently using it from a shared drive at the school and then free it up when they quit the program. I'm worried that opening the app up from two connections would cause horrible things to happen. (Haven't tried that myself -- I am not at the school.)

Any suggestions on how to keep this a one-user-at-a-time app with scripting? The easiest solution, of course, is to tell the teachers to take turns. And teachers, of course, always listen.

Thanks for any insights you might be able to offer.

[AxWald]

Hi,

you might use a semaphore - a file for instance. Once the program loads, it creates such a "lockFile", and when quitting it deletes it. And it doesn't load if such a file already exists.

For sure, you'd need to create a way to ignore this lockfile - your program might terminate for whatever unhappy reason without deleting its lockfile ...

Or, better, you might have program (always) running on the server (as service) where your teachers program needs to log in. A bit more esoteric, but more stable, too.

Hope I could help, have fun!

[jacque]

Nothing bad happens if more than one person opens a stack from a remote server, because the user only has a copy of the stack in memory on the local computer. Conflicts only happen if the stack tries to write data to a file on the server at the same time as someone else.

The easiest way to resolve this might be to have each team log in with a team name and then write their scores to a separate file on the server.

If you want to keep only one file, then typically your app checks a lock file and if it is busy, keeps checking until it is free, then writes a flag to the lock file, writes the scores data, and writes a "not busy" flag to the lock file.

To avoid issues if the flag is never deleted (the app or the server crashes for example) you can write the time to the file as part of the in-use flag. If more than a few minutes have elapsed, consider the file is okay to write to. Since writing to a file takes almost no time, a lapse of a minute or more would indicate something went wrong.

[stecxjo]

These are great suggestions, Axwald & Jacque, thank you. It occurs to me that I could simulate a server situation by using Dropbox or iCloud. I can even force-quit an instance to see what happens with an unexpected quit.

I will give your ideas a try. Mahalo!

Steve

[Norval Bard]

Hi,
I think I get the concept of a semaphore/flag check (confirms whether or not a file is open before attempting to make changes to it--right?), but I don't know how to set up the coding for it. Could someone point me in the right direction?
Thanks.

[AxWald]

Hi,

maybe this snippet will do?

Code: Select all

global gLockFile
-- the filename of the lockfile, a dummy of it 
-- should reside in the documents folder
global gDirectoryURL
-- the direcory on the server

on mouseUp
   if setLock() then
      answer "Lock set, it's ours now!"
   else
      answer "Somebody else is using it!"
   end if
end mouseUp

function setLock
   put URL gDirectoryURL into MyVar
   if gLockFile is in MyVar then
      return false
   else
      put specialFolderPath("documents") & slash & gLockFile into TheLockFile
      open file TheLockFile for write
      write the short name of this stack & tab & getMyUser() & \
            tab & the seconds to file TheLockFile  --  so the lock file knows who set it ...
      close file TheLockFile
      put theLockFile into URL (gDirectoryURL & gLockFile)
      return true
   end if
end setLock

Have fun!