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
> 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