Hi Steven,
> 1) do methods called with the @Asynchronous
> annotation share a single thread
> or can they take advantage of the n-pipes available?
The spec doesn't impose any requirements around the thread dispatch relationship between two distinct invocations on an @Asynchronous method. Typically, yes, container implementations will be using multiple threads. However, the exact determination of how many threads to use and when to wait for an existing thread vs. dispatch on a separate one are implementation details. In GlassFish, we use multiple threads but we don't currently expose the configuration for the thread pool that underlies the @Asynchronous dispatch. However it's a feature we're planning to add in the next release.
Keep in mind that the number of threads used is only one aspect of the concurrency behavior of Singletons. By default, Singletons have container-managed concurrency and each method has a default Lock access type of WRITE. That will ensure that no more than one thread has access to the bean instance at any one time. You can change this behavior by changing specific method access lock types to READ. Or, you can change the overall concurrency mode to BEAN MANAGED. In that case, the container will not do any locking and however many threads the container uses for concurrent client invocations will all be allowed to access the bean instance at the same time. The burden is then on the developer to ensure the integrity of the singleton state.
You might also want to take a look at chapter 4.8(Singletons) of the ejb spec.
As for auditing, EJB uses the same Interceptors as CDI so you can easily interpose on the asynchronous invocations just before control reaches the bean instance. The only real difference is the metadata used to associate the interceptor with the bean. In EJB, it's typically done using the @Interceptors annotation on the bean class or on the bean method, but can also be specified using ejb-jar.xml
> 2) is there any other way to do explicit concurrency
> in EE6? By explicit, I
> mean explicitly controlling the concurrency with
> Thread or perhaps allowing
> me to throttle thread usage on a block of
> (Asynchronous?) code through
> metadata.
Not really. In general at the application level in EE the containers are intended to be the ones controlling threads. The Servlet container doesn't prohibit the explicit use of threads but there aren't high-level EE thread-related constructs for what you're requesting.
>
> If needed, I am trying to port my "Enterprise Logger"
> (
> http://kenai.com/projects/elogger) to work in EE6.
> It works quite well in
> oth SE and EE5 environments right now. You can
> download the source from
> the SVN.
>
> Thanks,
>
> Steve
> [att1.html]
[Message sent by forum member 'ksak']
http://forums.java.net/jive/thread.jspa?messageID=398677