Hi,
I guess I'd be in favor of consistency.
So +1 to leave it not thread safe.
Jean-Louis
2012/9/5 Marina Vatkina <marina.vatkina_at_oracle.com>
> Experts,
>
> What do you think about thread safety of singleton beans session context?
> This problem applies not only to the BMC singleton, but also for those CMC
> singleton's that mix read/write access.
>
> Please let me know:
>
> a) if you think that SessionContext should be thread safe (and the spec to
> clarify in the proper places that "current" means "executing on the current
> thread"), or
> b) if you think it is a developer's responsibility to make sure the
> SessionContext is thread safe.
>
> Note that
> - EntityManager in JPA is not thread safe according to the JPA spec
> - UserTransaction is thread safe
>
>
> thanks,
> -marina
>
>
>
> -------- Original Message --------
> Subject: [ejb-spec users] Re: Section 16.15.2 question: is
> SessionContext obligated to be threadsafe?
> Date: Fri, 31 Aug 2012 14:27:09 -0500
> From: Jeremy Bauer <jrbauer_at_us.ibm.com>
> Reply-To: users_at_ejb-spec.java.net
> To: users_at_ejb-spec.java.net
>
>
>
> I know I’m a little late on this thread, but I don’t think SessionContext
> should fall under the umbrella of things a bean provider needs to
> synchronize. If you look at the methods on SessionContext, most of them
> are thread-local (getCallerIdentity, wasCancelCalled, etc.), others are for
> legacy 2.x homes (getEJBHome, etc.) which don’t apply to singletons. That
> leaves getTimerService, getUserTransaction, lookup, and getBusinessObject.
> In theory, these methods could return lazily initialized objects so they
> could require external synchronization. I’m guessing most vendors either
> don’t use lazy initialization or if they do, provide synchronization.
> Given that, I don’t think it is a stretch to require the container to make
> them thread safe in order to save the user the ugliness of having to
> synchronize the context.
> Taking this further, I think we could state the same (thread safety) of
> any object that can be injected, including EJB-specific TimerService and
> other EE artifacts that can be injected into a servlet. Even injected JPA
> entity managers are typically wrapped by the container and made thread
> safe. If we don’t want make such a bold assertion, the current wording is
> pretty non-specific, so I think it would at least be helpful to list all
> the servlet-injectable types that are thread safe in the EE spec (EE.5?)
> and reference it from the EJB spec. The EJB spec would expand on this list
> with SessionContext and TimerService for bean managed concurrency
> singletons. Since thread-safety may be provided as a result of
> synchronization of the EJB, it may also be essential to note that thread
> safety is not guaranteed if an object is passed over component boundaries
> (ex. passing a JPA EM from one component to another or returning it from a
> method invocation). Thoughts?
>
> -Jeremy
>
>
>
> From: Laird Nelson <ljnelson_at_gmail.com>
> To: users_at_ejb-spec.java.net,
> Date: 08/21/2012 08:07 PM
> Subject: [ejb-spec users] Re: Section 16.15.2 question: is
> SessionContext obligated to be threadsafe?
> ------------------------------**------------------------------**
> ------------
>
>
>
>
> On Tue, Aug 21, 2012 at 5:36 PM, Marina Vatkina
> <_marina.vatkina_at_oracle.com_ <mailto:marina.vatkina_at_oracle.**com<marina.vatkina_at_oracle.com>>>
> wrote:
> If we use the following text in the section 4.8.5 Singleton Session Bean
> Concurrency, it makes it a developer responsibility to make sure the
> context is thread safe, if more than one thread can access that singleton
> instance at the same time:
>
> "It is legal to store Java EE objects that do not support concurrent
> access (e.g. references to Java Persistence entity managers or stateful
> session beans) within the singleton session bean instance state. However,
> it is the responsibility of the Bean Provider to ensure such objects are
> not accessed by more than one thread at a time."
>
> Right; I take it then that an EJBContext is /definitely/ one of those
> "Java EE objects that do[es] not support concurrent access".
>
>
> (In any event, your answer is quite clear; I'll add the requisite locking.)
>
> Best,
> Laird
>
> --
> _http://about.me/lairdnelson_
>
>