EJB 3.x 2.1 Overall Goals
The Enterprise JavaBeans architecture will make it easy to write
applications: application
developers will not have to understand low-level transaction and state
management details,
multi-threading, connection pooling, or other complex low-level APIs.
Most methods are subject to the current execution context, so thread
safety is implicit.
TimerService can be invoked by any instance, so must (already) be thread
safe.
Lookup and references are covered by EJB 3.2 Core PD-2 3.4.9 Concurrent
Access to Session Bean References.
All methods of UserTransaction execute on the current thread only.
So unless I missed something, thread safe it is.
Carlo
On 09/05/2012 02:11 AM, Marina Vatkina wrote:
> 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>> 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
>