This is perhaps really a spring question, but the readers of this list must have hit this before.
SEI classes are reentrant. CXF services are frequently deployed in Spring and constructed with Spring-managed beans. Spring doesn't seem to offer much in the multithreading department. To be a bit more concrete, consider an SEI class that is handed a set of supporting beans via IoC. If those objects are reentrant themselves, well, life is good. What if they are not? The SEI can synchronize and single-thread their use. Effective, but not popular when trying to achieve high usage of multiple processors. Or, we could abandon IoC here, and let the SEI make Spring calls to obtain new instances of the beans (declaring them appropriately) and stash them in thread local storage. This would work best if CXF was keeping some sort of pool of SEI's around to go with the threads, and I haven't researched that yet. It seems a shame to have to decorate the SEI class with a bunch of spring interactions. I suppose that a trick could be had: an intermediate bean that served as a factory for the non-thread-safe objects, and which hid the interactions with the IoC container inside of itself.
