Locking mechanism for edited folders in JobScheduler Editor

Desired Behavior

• JobScheduler Editor should prevent two users from editing the same file at the same time.
• Even when using Open Hot Folder (By FTP) the locking should be performed per file (and not per directory).

Implementation

• Locking is provided at folder level, not at file level. The reason is that
  • the complexity of this feature should be reduced to make it happen.
  • JOE cannot decide what files a user will start to edit. Instead (S)FTP commands would have to be sent subsequently.
• A lock file (e.g. joe.xml.lock) can be used to implement this (as in MS Word).
• JOE should respect failure to remove a lock file to prevent a situation when a JOE instance was not terminated correctly, e.g. if a connection has been lost.
• Lock file contents
  • The lock file contains the following information about the operating system user and the lock file creation date, e.g.
    • user: Uwe Risse
    • date: 2015-09-24T07:49:18.625Z
    • The datetime is stored in UTC
    • The datetime is shown in the local timezone with the format yyyy-MM-dd HH:mm:ss
  • Additional information could be added if required
• Behavior with lock files
  • JOE checks if a lock file exists at the beginning of an editing session:
    • an editing session begins when a folder will be opened.
    • If no lock file exists then a new lock file is written and processing continues.
    • if a lock file exists then
      • JOE reads the contents of the lock file and displays the user name and date found from the lock file. The date value is converted to the local time zone of the JOE platform.
      • JOE asks the user if he wants to proceed anyway, i.e. wants to edit files in that folder. In this case JOE overwrites the lock file.
  • JOE writes the lock file before editing of files in folder starts.
  • JOE removes the lock file at the end of the editing session
    • If the user has changed in the meanwhile, the file remains in the folder.
  • If the user name from the lock file does not correspond to the current user then a warning is displayed and the user is asked if he wants to proceed. If yes then the files are save but the lock file will not be overwritten. The check takes places every time a folder is going to be saved.
  • When saving the folder and no lock file is available, a new lock file will be generarted.
  • If a lock file is not accessible, e.g. not readable or writeable, then JOE presents a warning and asks the user if he wants to proceed. If yes, then the lock file is ignored for the editing session.

current situation
While testing it occurs, that if more than one instances of JOE are started, an exception occurs when closing the JOE instances. It doesn´t matter in which order the instances are startet, the error always occurs after the first instance is already closed and the second instance is about to be closed.