Serialization of ExecutionContext in GML loader slows down large load operations

[stephanr]

The storage of object IDs and references in order to later check the referential integrity of a load operation means that a large amount of IDs and references are stored in ExecutionContext.

deegree3/deegree-tools/deegree-tools-gml/src/main/java/org/deegree/tools/featurestoresql/loader/FeatureReferencesParser.java

Lines 71 to 80 in 86bbe91

	private void putInContext( String featureId, List<String> references ) {
	ExecutionContext executionContext = stepExecution.getExecutionContext();
	if ( !executionContext.containsKey( FEATURE_IDS ) )
	executionContext.put( FEATURE_IDS, new ArrayList<String>() );
	( (List<String>) executionContext.get( FEATURE_IDS ) ).add( featureId );
	if ( !executionContext.containsKey( REFERENCE_IDS ) )
	executionContext.put( REFERENCE_IDS, new ArrayList<String>() );
	( (List<String>) executionContext.get( REFERENCE_IDS ) ).addAll( references );
	}

It was observed that during a large loading process (13 million objects), the time per chunk increased abruptly after approx. 30 minutes. During an analysis of a dump (.hprof) of the JVM it was determined that this is due to the serialization of the ExecutionContext.

For more background see spring documentation at https://docs.spring.io/spring-batch/docs/4.3.5/reference/html/index-single.html#executioncontext