Re-use SAXParserFactory in JAXBContextImpl for better performance

[laurentschoelens]

Follow up issue of jakartaee/jaxb-api#284

This method : org.glassfish.jaxb.runtime.v2.runtime.unmarshaller.UnmarshallerImpl#getXMLReader should use an shared instance of SAXParserFactory hold by JAXBContextImpl

[winfriedgerlach]

Thx for picking this up, @laurentschoelens! Another way this could be improved would be to use the unmarshallerPool in JAXBContextImpl. It's public but there is no documentation and the Pool itself is in com.sun subpackage, so it's a bit unclear whether/how this should be used in production.

I spent a lot of time benchmarking yesterday, but my numbers are unfortunately inconclusive, so I cannot say what optimization would really be worth the trouble. If you conduct tests yourself or write documentation on "how to use", pls consider also multi-threaded use case ("one thread per request" model, what needs to be synchronized etc.).

[laurentschoelens]

Amend commit : Fixed init before setting into class instance

[laurentschoelens]

Thx for picking this up, @laurentschoelens! Another way this could be improved would be to use the unmarshallerPool in JAXBContextImpl. It's public but there is no documentation and the Pool itself is in com.sun subpackage, so it's a bit unclear whether/how this should be used in production.

Didn't get what you meant by using the Pool. The pool itself is on having a pool of marshaller and unmarshaller.

Since we are sharing the SAXParserFactory at the context level, all elements from the pool will inherit this optimization

[winfriedgerlach]

Yes, sorry, maybe my comment was confusing. These are 2 different aspects targeting the same issue: Making access to Unmarshallers faster.

• With the solution discussed in the ticket title and your PR, we can make creation of Unmarshallers faster. Which is very nice and I totally welcome this change!
• With the Pool approach we could re-use Unmarshallers instead, so the time it takes to create Unmarshallers is not as critical any more (though fast creation is still nice of course).

See JAXB User Guide:

Which approach is faster is probably use-case dependent.

[laurentschoelens]

Creating an instance in the Pool would still be expensive by not sharing the SAXParserFactory so I think this would benefit the two use-cases. The only part not fixed is on initial creation and on multi-threaded-heavy-loaded environment

[winfriedgerlach]

Fully agree.

Yet Another aspect: The same "not re-using a factory" issue can be seen in MarshallerImpl.marshal(Object, XMLEventWriter):
The constructor of XMLEventWriterOutput calls to XMLEventFactory.newInstance() which again triggers the expensive FactoryFinder.find().

MarshallerImpl.marshal(Object, XMLStreamWriter) is not affected since XMLStreamWriterOutput uses a hard coded class name instead (this is also mentioned in XMLStreamWriterOutput's class Javadoc).

Since we don't marshal much in our product, this doesn't affect me, but it may affect others.