jcabi
Extensive global synchronizations
These global synchronizations around resource-intensive code should be avoided: https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSLDocument.java#L275 https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSDDocument.java#L168 https://github.com/jcabi/jcabi-xml/blob/master/src/main/java/com/jcabi/xml/XSDDocument.java#L184
@lightoze this is on purpose, because DOM is not thread-safe, but we promise that our classes are thread-safe.
Let's look at XLSDocument case first. You create local TransformerFactory and Transformer instances, so you should not worry about them. DOM itself is a potential source of a problem (when the same document is used in concurrent transformations), but in this case synchronization should be on xml, xml.node() or whatever.
The problem is that creating a local instance of Transformer doesn't make it thread safe :( I believe it's full of static properties inside.
Do you want to say that it's impossible to run two concurrent XSL transformations inside the same JVM?That's ridiculous. Transformer documentation says clearly: An object of this class may not be used in multiple threads running concurrently. Different Transformers may be used concurrently by different threads.
Yes, that's exactly what I'm saying and I have a test that proves it. Take a look: https://github.com/jcabi/jcabi-xml/blob/master/src/test/java/com/jcabi/xml/XSLDocumentTest.java#L72-L98
Try to remove synchronization and run mvn clean test and you will see what happens.
Just did exactly what you suggested - the test is not failing with removed synchronization. Can you reproduce it yourself now? Tested with JRE 1.8.0_31 and 1.7.0_76