protegeproject
Provide locking mechanism for the metaproject
The locking mechanism will allow only one client to edit/update the metaproject at any one time.
@bdionne What do you think with this idea to securing an opened metaproject file? http://stackoverflow.com/questions/122282/can-the-java-file-method-canwrite-support-locking
Another approach is to have one process write the file with a name that your process
won't recognize, then rename the file to a recognizable name when the write is complete.
On most platforms, the rename operation is atomic if the source and destination are the
same file system volume. The name change might use a different file extension, or even
moving the file from one directory to another (on the same volume).
As long as the admin is opening (or accessing) the metaproject, the file name is randomly changed so that other users that would like to access the file will receive a file-not-found exception thus signaling file is being edited by someone else.
That's surely one way at the file system level. I was thinking of possibly only allowing one admin at a time to perform edits on the metaproject.
The only time a user will be updating the metaproject is if 1. they are an admin, and 2. they've opened the metaproject gui. Otherwise for normal client/server use the metaproject is only being read.
In the case where 1. and 2. obtain, which presumably we can detect on the server or use different APIs in the client, we could note that user's session token and only allows POSTs of the metaproject from that token. Maybe we'd use a different expiry on those tokens to deal with the scenario where an admin opens it up to edit then goes home for the day.
