about "i#52: lock database"

[Vlad Skvortsov]

Ivan Glushkov wrote:
> Hello.
>
> Description to i#52: "An issue database should be locked before performing  
> changes in it."
>
> My thoughts:
> We have to lock the database while perfoming changes in order to forbid  
> other users to corrupt it.
>   

I suggest we lock the database in DITrack.DB.Database.__init__() and 
unlock it in the __del__() method.

> It has some sense only when several users work with the same copy of  
> ditrack.
>   

Yes. And also if a single user runs two instances of DITrack concurrently.

> Locking might be done with some special file inside "issues" directory,  
> for example .lock.<user>.date
>   

.../issues/.ditrack/LOCK, containing the process PID and active write 
lock on the whole file contents.

> After making all changes lock file should be deleted.
> If lock file still exists nobody is permitted to make any changes. In this  
> case diagnostic message will appear, something like "Can't execute %s  
> command, user %s at %s had locked database (file issues/%s)" % (user,  
> date, filename).
>   

The algorithm should look like this:

If the lock file doesn't exist, proceed with the execution.
Otherwise,
    if there is no lock on the file,
       say "Database <path>: stale lock"
       exit;
    else
       if there is sensible PID in the file,
          say "Database <path> locked by PID <PID>"
          exit;
       else
          say "Database <path> locked with the lock file corrupted"
          exit.

> If database was locked too long ago (2 hours?) we should have some option  
> to force making changes in database.
>   

We should rather have a 'cleanup' command, which will remove the lock.

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com