First, I've been pretty quiet on this list lately,
since I figure that most of you are much more deserving
of opinions than I am about issues surrounding transaction
facilities etc that I never deal with.
And officially, the following is off-topic for jsr236.
But your thoughts on it would be very welcome.
As I mentioned briefly a few months ago, JDK8 will
include some builtin lambda-based parallelism, mainly
via the Stream API, allowing things like:
myCollection.parallelStream().forEach(e -> use(e));
that will do a parallel for-each loop.
The implementation of this, plus other (non-Stream)
parallelism features, rely on the commonly-accessible
single ForkJoinPool.commonPool. This is completely unlike
ThreadPoolExecutor and other pools amenable for use as
ManagedExecutors: It uses work-stealing of (usually)
recursively-divided subtasks, processed and/or further subdivided
by any available worker-thread. This allows rapid parallel
branching of very small tasks that can in principle speed up
processing of even "ordinary" bulk collection operations.
But doing this rules out techniques like loading a bunch
of context every time a worker accepts a task: work-stealing
is randomized, opportunistic, and often based on subtasks
of a user-level operation, not the operation itself.
Plus, every ounce of overhead you place in front of
the initial parallel branch-out acts like a ton of
bricks in limiting speed-ups. (This is just Amdahl's
law at work.)
For now, our main thoughts on how to integrate this with
EE stuff have focused only on how to easily disable it!
In JDK8, there will be properties you can set that cause
the commonPool to not maintain any threads at all, which
causes all "parallel" submissions to actually be performed
by their calling threads. Some/many/all EE systems may
decide to take this option.
But I think there is some sentiment to do something
better than this. No one has come up with a compelling
alternative yet. If you do, please let me know!
-Doug