On Tue, 18 Sep 2007, Rasmus Fogh wrote:
> Locking the files would not be that easy to set up. In version 1.1 we
> can have several Project.xml all pointing to the same set of data. This
> would make sense if e.g. you were working on different constraint lists
> and wanted the 'currentConstraintStore' to point to different files.
OK. Looks like things are definitely going to get more complicated.
> Proper handling of concurrent access requires a database. Anything we
> could do in a file implementation would have to be simple and limited,
> otherwise we would end inventing our own DB system.
Don't even think of going there!
> I would like a more precise list of the kind of situation people want us
> to deal with.
It should be rare that two users try to modify the disk copy of a project
at the same time. In most situations filesystem permissions should
prevent this from happening.
More likely is that one user accidentally/intentionally opens two copies
of the same project. Under such circumstances, it would be nice to warn
the user of the dangerous waters they have entered - you might not want to
disable functionality because who knows precisely why the second copy had
been opened.
If we accept the argument for a warning, how could it be implemented? A
simplistic way to do this would be to create a file called e.g. "lock" in
the project specific directory on opening a project and remove it on
closing. It could even contain the python process' PID for validation.
Then another analysis process opening the same project would know to issue
the warning. If the lock had not been removed (e.g. due to a previous
crash), it would be easy for the user to find & remove it and reopen the
project. There's probably cleverer/more portable ways of doing this.
Brian
--
Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk
Division of Biochemistry & Molecular Biology,
Institute Biomedical & Life Sciences,
Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
Tel: 0141 330 5167/6459/3089 Fax: 0141 330 8640
|