I like this idea.
Is there something similar in the ee concurrency spec?
Is this kind of "wait for everyone" sometimes called join?
I haven't kept up with the async method api so would appreciate a more
complete example with returned results and both client and server beans.
thanks
david jencks
On Aug 5, 2008, at 1:42 AM, David Blevins wrote:
Had an interesting idea I think I might propose to the EJB 3.1
Expert Group. Wanted to run it by here as I can't seem to think of
a good name for it.
Essentially, many people who want async methods don't actually want
fire and forget. We've already addressed this somewhat with the
ability to return a container controlled java.util.concurrent.Future
instance to the async method caller. It doesn't really address the
parallelization scenario where they want to call several async
methods and wait for them all to complete. Holding onto a handful
of Future objects without the benefit of something like the NIO
Selector API (which is still pretty terrible) is just not going to
cut it.
The idea is to introduce something like a @Resynchronize annotation
that could be applied to business methods on the bean class. A
business method or callback with the @Resynchronize annotation would
block until all the all the async methods it calls have completed.
So for example:
@Resynchronize
public void goTeam() {
fooBean.red(); // async method
barBean.green(); // async method
bazBean.blue();
}
At the start of the goTeam() method the container would ready itself
to track async calls. When the bean code calls the red() and
green() methods the container will track those calls and when the
goTeam() method returns to the container, the container will block
the thread till both red() and green() complete. When both are
completed, the container will return control to the caller of
goTeam().
Internally if we had something like a CountDownLatch that could
count up as well as down, we'd be set. Any ideas there?
Also, not sure @ Resynchronize is the best annotation name.
-David