TRPL

1. com.goldencode.p2j.schema.ImportWorker$SqlRecordLoader
2. com.goldencode.p2j.convert.NameMappingWorker$ProgramInfo
3. com.goldencode.p2j.convert.NameMappingWorker$MethodInfo
4. com.goldencode.p2j.uast.CallGraphWorker$CallSiteHint
5. com.goldencode.p2j.convert.BufferScopeWorker
6. com.goldencode.p2j.convert.DatabaseReferenceWorker
7. com.goldencode.p2j.convert.ExpressionConversionWorker
8. com.goldencode.p2j.convert.I18nWorker
9. com.goldencode.p2j.convert.IndexSelectionWorker
10. com.goldencode.p2j.convert.NameConverterWorker
11. com.goldencode.p2j.convert.NameMappingWorker
12. com.goldencode.p2j.convert.UnreachableCodeWorker
13. com.goldencode.p2j.pattern.FileOperationsWorker
14. com.goldencode.p2j.pattern.TemplateWorker
15. com.goldencode.p2j.persist.orm.DDLGeneratorWorker
16. com.goldencode.p2j.preproc.PreprocessorHintsWorker
17. com.goldencode.p2j.report.ReportWorker
18. com.goldencode.p2j.schema.DataModelWorker
19. com.goldencode.p2j.schema.DmoAsmWorker
20. com.goldencode.p2j.schema.ImportWorker
21. com.goldencode.p2j.schema.P2OAccessWorker
22. com.goldencode.p2j.schema.SchemaWorker
23. com.goldencode.p2j.uast.CallGraphWorker
24. com.goldencode.p2j.uast.JavaPatternWorker
25. com.goldencode.p2j.uast.ProgressPatternWorker
26. com.goldencode.p2j.uast.UastHintsWorker
27. com.goldencode.p2j.xml.XmlPatternWorker

If you look at DataModelWorker, you will see the static state is in a WorkArea class, to be context-local. This (and other pattern classes) were changed like this, to allow runtime conversion of queries; other classes which are not yet changed I think should move to the same context-local approach.

Constantin Asofiei wrote:

If you look at DataModelWorker, you will see the static state is in a WorkArea class, to be context-local. This (and other pattern classes) were changed like this, to allow runtime conversion of queries; other classes which are not yet changed I think should move to the same context-local approach.

Got it. So, I need to move all the static variables (shared data) into a WorkArea inner class that ensures thread safety for all the workers used in TRPL.

Should static methods be kept or make them non-static and use them through a class instance?
DataModelWorker:

-            XmlPatternWorker.createAst(XmlTokenTypes.CONTENT, schema + ".impl", elAttr);
+            context.get().xpw.createAst(XmlTokenTypes.CONTENT, schema + ".impl", elAttr);
          }

          this.schemaElem = schemaElem;
@@ -1101,7 +1102,7 @@
             while (attr != null)
             {
                String key = attr.getText();
-               String value = XmlPatternWorker.getAttributeValue(attrs, key);
+               String value = context.get().xpw.getAttributeValue(attrs, key);

                info.putAttribute(key, value);

@@ -1342,5 +1343,7 @@
    private static class WorkArea
    {
       /** Root of the target tree currently being processed (created). */
       private DataModelAst root = null;
+
+      private final XmlPatternWorker xpw = new XmlPatternWorker();
    }
 }

There is nothing intrinsically unsafe with static methods. Any state they access will need to be context local OR synchronized/protected to be thread-safe.

I went through all the workers listed above and checked where the variables are good to store in the context-local. I ignored all the constants or immutable lists, as they are populated in a static block and then just referenced. Most of the workers were in this situation, having logs or constants. I made these changes in the task branch 1752a/15886.