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):
Priority: 5 - Normal => 7 - High
Assigned to: None => lraae
==============================================================================
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: None
Privacy: Public
Percent Complete: 0%
Assigned to: lraae
Open/Closed: Open
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).)
_______________________________________________________
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/
