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
