[
https://jira.duraspace.org/browse/DS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841#action_17841
]
Tim Donohue commented on DS-712:
--------------------------------
Richard,
Correct -- restoring individual AIPs to the same repository would be
unaffected. However, restoring an entire repository from scratch via AIPs
would be affected (in fact, I think it'd be highly likely to encounter this
scenario). It essentially stems from decisions made during the AIP work (so,
this is not a necessarily flaw in current versions of DSpace, but is a flaw in
Trunk code):
* When restoring an AIP, the Handles are restored as they were, but DB IDs may
be different.
* When restoring an entire Site, you are only restoring objects which exist
within the AIPs. Although this seems obvious, it's an important point, and
you'll see why in a moment.
As a basic example, you may have 100 AIPs, with handles ranging <prefix>/1
through <prefix>/103 -- and maybe you had deleted 3 objects over time (e.g.
<prefix>/2, <prefix>/35, and <prefix>/40), hence why your final handle suffix
is larger than the number of AIPs.
When you go to perform a full restore this full set of AIPs to an empty DSpace,
you'll end up with issues. Although the same handles will be restored, the
maximum "handle_id" value in the "handle" database will only be 100, as you
only re-created 100 objects. As soon as you go to create a new object, DSpace
will attempt to create an object with the handle <prefix>/101. But,
obviously, an object is already using that handle, and the creation process
will fail. At this point, you'll be unable to create new objects in DSpace
(unless you manually bump up the value of "handle_seq" to 104, in this example,
to avoid DB conflicts).
Although I get your point that this may not be as critical with most migrations
or most single restores, I think it is highly critical if we would want to
support full site restores from an AIP backup. So, I think we need to have
some sort of resolution for 1.7, or else we need to explicitly state that full
restores from AIPs may cause the DSpace DB to enter an unstable state.
> DSpace Fails to Check if a Handle is already assigned before assigning a new
> handle
> -----------------------------------------------------------------------------------
>
> Key: DS-712
> URL: https://jira.duraspace.org/browse/DS-712
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.7.0
> Reporter: Tim Donohue
> Assignee: Tim Donohue
> Priority: Blocker
> Fix For: 1.7.0
>
>
> Not sure how this hasn't come up before, but I just noticed this in terms of
> testing the new AIP Backup/Restore functionality (DS-466).
> DSpace currently makes a highly flawed assumption when assigning new Handles.
> It will *always* assign a Handle equal to the next available value in the
> 'handle_seq' (which is just the max value of 'handle_id' in the 'handle'
> table). See the HandleManager.createHandle() method.
> This becomes extremely fragile when you have content which has been migrated
> or restored from another DSpace (for example, via the AIP backup/restore
> feature). In those instances, it you may end up restoring/migrating content
> that looks like this:
> handle_id = 44 (or whatever the next value in 'handle_seq' is)
> handle = 123456789/50 (or whatever the restored handle should be)
> Once the value of 'handle_id' reaches the suffix value of a restored handle,
> then you will run into database conflicts & will be unable to submit any new
> content into DSpace. So, in the above example, as soon as 'handle_seq" gets
> to the value of 50, Dspace will attempt to assign a new handle of
> '123456789/50' to the next object created. However, as that handle is
> already in use, the new object will always fail to be created. In other
> words, the DSpace system will fail to accept any new objects.
> The fix would be to first ensure a handle is *not* already in use before
> assigning it -- essentially looking for the next available handle (rather
> than the next value of 'handle_seq") before assigning the handle. However, I
> need to determine a reasonable way to locate the next available handle
> (preferably something that will scale relatively well for larger installs).
> Ideas / thoughts / brainstorms welcome. I've marked this as a "Blocker" for
> DSpace 1.7.0, as it essentially makes your DSpace unusable if you were to
> encounter this bug. (The only way to get around this issue if you
> encountered it is to manually increase your "handle_seq" so that it's greater
> than the largest handle suffix in your system.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
