0

Currently our application is not leveraging the xml transformers that spring integration provides. Instead it is creating one JaxbContext then from that JaxbContext creating a pool of JAXB unmarshallers/marshallers and wiring these into service activiators. We create the pool so as to not incur the cost of creating marshallers and unmarshallers for each operation.

As part of a re factoring effort we decided we should make use of the xml transformers. While attempting to implement we've discovered that the org.spring.oxm.Marshaller implementations do not support pooling of marshallers/unmarshallers, because UnmarshallingTransformer by spring integration expects and implementation of org.spring.oxm.Marshaller. Each implementation of org.spring.oxm.Marshaller creates an new javax.xml.bind.Unmarshaller when the unmarshal method is called

Finally I've given enough background for my question. Is creating a new Unmarshaller for each unmarshal operation not a performance concern? According to the jaxb ri documentation it does impact performance. As a counter argument a lead on jaxb project states that they are lightweight

Community
  • 1
  • 1
user216716
  • 1
  • 1

2 Answers2

1

Probably, a good idea is to move marshallers to java. Using Marshaller for different objects and validation handlers are really heavy and one of the top memory eating monsters.

Harsh Mighlani
  • 89
  • 1
  • 12
0

You can safely reuse JAXBContext, but I have never seen guarantees that Marshaller and Unmarshaller instances were thread-safe and/or reusable.

This essentially means that you are not guaranteed that pooling marshallers/unmarshallers is safe. This would be a sufficient reason not to pool them.

I also doubt this is much of a performance gain. Marshallers/unmarshallers hold the current marshalling/unmarshalling state so there's not much to save by reusing marshallers/unmarshallers.

lexicore
  • 42,748
  • 17
  • 132
  • 221