Bug #438


Intermittent Version Numbering Problem

Added by Dan Higgins almost 21 years ago. Updated about 20 years ago.

morpho - general
Target version:
Start date:
Due date:
% Done:


Estimated time:


If one creates a datapackage and then repeatedly changes one of the documents in
the package (e.g. the eml-access doc; just say it is a new doc without actually
changing anything), perhaps 1-2 times out of 10, an error will occur which says
"The file you are attempting to updata has been changed by another user ...".
Apparently the sequence number has become out of sync. Completely removing local
copies and working from Metacat versions does not fix the problem - i.e. not
further editing can be done.

The problem is apparently related to the "getMetacatInputStream" method in
'ClientFramework' class. This method has makes three attempts to get a network
connection due to a problem in the HTTP connection class. This bug apparently
occurs when the first embedded 'try' in this method fails. Somehow the version
number is getting incremented in Metacat but not in the package!

Apparently, Morpho needs some sort of transaction management in order to recover
when part of a datapackage updata works and part does not.

Related issues

Blocks Metacat - Bug #213: transaction support for packagesNewJing Tao04/09/2001

Actions #1

Updated by Matt Jones almost 21 years ago

The observation about transaction support is also something we have recognized
as a need for Metacat. Bug 213 describes the metacat transactions, and so I
have made this bug dependent on that one.

Actions #2

Updated by Dan Higgins almost 21 years ago

Further study of this bug shows that it probably happens when a document other
than the dataset doc is edited. The edited document is updated and then the
dataset must be updated with new ids. If that fails, then the edited document
has a version number 1 greater than that in the dataset doc, but that doc is NOT
part of the datapackage. Trying to update the datapackage (which references the
older version than fails because a new version exists on metacat.

A (partial) fix is to try and roll back any new versions if any part of the
transaction fails. A new update routine has been written to do just that. That
code is currently being tested.

Actions #3

Updated by Dan Higgins about 20 years ago

I have been unable to recreate the problem as described with the current version
of Morpho (10/7/2002). I think we have probably fixed the original problem with
code updates. I am thus marking this bug as resolved. (Dan Higgins)

Actions #4

Updated by Redmine Admin over 9 years ago

Original Bugzilla ID was 438


Also available in: Atom PDF