Project

General

Profile

Bug #438

Intermittent Version Numbering Problem

Added by Dan Higgins almost 18 years ago. Updated about 17 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
morpho - general
Target version:
Start date:
02/28/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
438

Description

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 packagesNew04/09/2001

History

#1 Updated by Matt Jones almost 18 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.

#2 Updated by Dan Higgins almost 18 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.

#3 Updated by Dan Higgins about 17 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)

#4 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 438

Also available in: Atom PDF