Known issue. We may have an answer for you before too much longer; part of
the DTM work has involved restructuring our thread management.
Basically: The challenge is that we Really Want to do incremental parsing,
so we can read only as much of the source document as we need (avoiding
wasted work) and so we can start producing output as soon as we start
reading (lower latency). Unfortunately XSLT has to carry a lot of state
information around, and thus trying to drive it entirely in terms of SAX
events doesn't work very well. So we wind up wanting to run the SAX parser
and the XSLT processor as coroutines ... and currently the only
general-purpose coroutine mechanism available in Java involves threading.
But there are a number of things we can do about this. We've restructured
what work gets done in each thread. We've wrapped the coroutine mechanism
under an API. In the specific case of the Xerces parser, we've set up the
coroutine calls to actually invoke Xerces' nice-but-nonstandard incremental
parsing mechanism (which is already a coroutine of sorts) rather than using
our threading wrapper. And we've set up a mode which will parse fully
before you beging processing, which will avoid the thread even for
non-Xerces parsers (at the cost of increased latency and possibly reduced
throughput as well).
So better EJB support is on its way. But those changes are still considered
experimental.
