[UIMA-6348] Race-condition in TypeSystemImpl commit

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.2.0SDK
• Component/s: Core Java Framework
• Assignee: Richard Eckart de Castilho
• Reporter: Richard Eckart de Castilho
• Created: 31/Mar/21 07:15
• Updated: 01/Apr/21 09:08
• Resolved: 01/Apr/21 09:08

Description

In principle, it is possible to obtain a type object from one CAS and to use that type object to create a feature structure in another CAS:

    TypeSystemDescription tsdA = new TypeSystemDescription_impl();
    tsdA.addType(MY_TYPE, "", CAS.TYPE_NAME_ANNOTATION);

    TypeSystemDescription tsdB = new TypeSystemDescription_impl();
    tsdB.addType(MY_TYPE, "", CAS.TYPE_NAME_ANNOTATION);

    CAS casA = CasCreationUtils.createCas(tsdA, null, null, null);
    CAS casB = CasCreationUtils.createCas(tsdB, null, null, null);
    
    Type typeA = casA.getTypeSystem().getType(MY_TYPE);
    Annotation annB = (Annotation) casB.createAnnotation(typeA, 0, 0);
    annB.addToIndexes();
    casB.removeFsFromIndexes(annB);

If both CASes have been initialized with a semantically equivalent type system, UIMA will actually return the same type object in this case due to "typesystem consolidation" being performed in the TypeSystemImpl. However, if we turn off typesystem consolidation or if the type systems are different and just incidentally use the same type names, the type object is different.

In highly concurrent situations, the synchronization in TypeSystemImpl.commit is insufficient to ensure that the consolidated type system is always returned. This leads to a situation where more than one type system instance with the same type may exist.

Finally, there is a sanity check done in sorted FS indexes that the type of the index corresponds to the type of the feature structure being removed. If type consolidation worked, this is the case - but not if it failed due to the insufficient synchronization

Issue Links

• links to: GitHub Pull Request #116