This is an automated notification sent by LCG Savannah.
It relates to:
task #6965, project CDS Invenio
==============================================================================
LATEST MODIFICATIONS of task #6965:
==============================================================================
Update of task #6965 (project cdsware):
Status: None => Done
Percent Complete: 80% => 100%
Open/Closed: Open => Closed
_______________________________________________________
Follow-up Comment #2:
Closer examination of the code revealed that the tmp file already does the
job of locking the record while further lock checks are run. However the tmp
file was not deleted if it turned out that the record should be locked for
editing, but this is now fixed.
==============================================================================
OVERVIEW of task #6965:
==============================================================================
URL:
<http://savannah.cern.ch/task/?6965>
Summary: BibEdit, record locking, and task queue
Project: CDS Invenio
Submitted by: simko
Submitted on: 2008-05-30 10:28
Should Start On: 2008-05-30 00:00
Should be Finished on: 2008-05-30 00:00
Category: BibEdit
Priority: 7 - High
Status: Done
Privacy: Public
Percent Complete: 100%
Assigned to: lraae
Open/Closed: Closed
Discussion Lock: Any
Effort: 0.00
_______________________________________________________
The BibEdit web interface currently locks records for editing in the
following way. If a user U1 starts to edit record R, then in tmpdir a
temporary record is created (serialized) upon which U1 operates, and when
another user U2 would like to open R for editing too, the presence of
temporary serialized record prevents this. (Unless the temporary record is
way too old and was never submitted in which case U2 is granted access.)
This works well during the time U1 actively edits the record. However, when
U1 submits her changes, they are not executed immediately, in case there
might be another (lengthy) bibupload in the task queue. (This is less
probable with our current bibsched task priority facility, but it can surely
happen.) Hence it may be that user U3 starts to edit record R when the
changes done by user U1 are not yet present in the database.
This is not good and we have to prevent this.
A simple technique would be for BibEdit to consult the bibsched queue status
(e.g. via "bibsched status" CLI), check if there is any "bibupload" job with
a WAITING status in the queue, and if yes, then refuse to allow web editing
records at that moment.
A simple improvement to this technique is to compare the record ID of the
record-to-be-edited and check which records any WAITING bibupload job might
concern. If they act on the same record, then refuse editing. If they act on
different records, then allow editing.
(This technique will still not allow multi-cataloguing work in parallel on
different tags, e.g. user U1 editing/proofreading titles and user U2
editing/proofreading references. While this would be fully safe to allow, we
don't have an easy way to recognize this now, because the current BibEdit
produces full MARCXML for record replacement via "bibupload -r". An ultimate
solution to this problem will come later with INSPIRE developments when
record editing and updating will behave in form of submitting diffs. This
will diminish possible conflict window and allow more intelligent merging of
diffs (git-style).)
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: 2008-06-24 10:31 By: Lars Christian Raae <lraae>
Closer examination of the code revealed that the tmp file already does the
job of locking the record while further lock checks are run. However the tmp
file was not deleted if it turned out that the record should be locked for
editing, but this is now fixed.
-------------------------------------------------------
Date: 2008-06-23 14:23 By: Lars Christian Raae <lraae>
Added CFG_BIBEDIT_LOCKLEVEL - when a user tries to edit a record being edited
by another user, the lock level determines when it is permitted to do so.
Levels are 0-3 and are described in invenio.conf.
What remains is to implement a lock while this check runs. In particular the
level 3 lock check can possibly take som time to complete and the record in
question should be locked while this check completes.
_______________________________________________________
Carbon-Copy List:
CC Address | Comment
------------------------------------+-----------------------------
3871 | -UPD-
1576 | -SUB-
==============================================================================
This item URL is:
<http://savannah.cern.ch/task/?6965>
_______________________________________________
Message sent via/by LCG Savannah
http://savannah.cern.ch/
