Experts,
Those of you who were on the EJB 3.1 EG, do you remember if this issue
had been discussed when BMC singletons were being added?
thanks,
-marina
Carlo de Wolf wrote:
> 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
>>
>