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
--
_http://about.me/lairdnelson_