These were both great answers, I appreciate the time both responders took.
I'll indeed do some more research on Bean Managed Concurrency, I believe
this is the route I'll want to go in order to
achieve consistent performance/operations across vendors (although I don't
understand why anyone would want anything other than GlassFish!) =)
Thanks again,
Steve
On Fri, Apr 23, 2010 at 9:17 AM, <glassfish_at_javadesktop.org> wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>