[Dpr-development] [ dpr-Bugs-3612956 ] Job Normalisation step very slow for archive file

[SourceForge.net <no...@so...>]

Bugs item #3612956, was opened at 2013-05-08 22:07
Message generated for change (Comment added) made by terryoneill
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=676456&aid=3612956&group_id=116934

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Preservation
Group: None
Status: Open
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: Terry O'Neill (terryoneill)
>Assigned to: Kirti Chennareddy (kirtic)
Summary: Job Normalisation step very slow for archive file

Initial Comment:
The Transfer Job Normalisation step and Reprocessing Job Normalisation step are both very slow when processing a file that results in a lot of Archival Information Packages (i.e. Xena files) being creating.  When running with show_sql set to true (hibernate option) it is apparent that there are multiple unnecessary updates of the aip_creation_record table that seem to increase in number the more AIPs that have been processed for a single input data object.

----------------------------------------------------------------------

>Comment By: Terry O'Neill (terryoneill)
Date: 2013-05-08 22:31

Message:
Fixed on performance branch and assigned to Kirti to test.  This fix
involved removing all cascading options that were set for the
ReprocessingJobAIPCreationRecord and TransferJobAIPCreationRecord classes
on the getXenaProcessingRecord() function.  Note that this function is used
in a number of contexts so steps other than the Job Normalisation steps
should also be tested to ensure no change in functionality at other steps.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=676456&aid=3612956&group_id=116934