Experts,
Unless somebody objects, I'm noting in the spec that SessionContext must
be thread safe.
-marina
Marina Vatkina wrote:
> This is what JPA spec says (see 7.2 Obtaining an EntityManager):
> "An entity manager must not be shared among multiple concurrently
> executing threads, as the entity
> manager and persistence context are not required to be threadsafe."
>
> It is expected that EMF is injected into a servlet or EM is looked up
> by the executing method.
>
> I don't see a problem with adding a requirement to guarantee thread
> safety of the SessionContext, but I'd like to hear more votes in favor
> of this feature (so far I have 2 for and 1 against).
>
> -marina
>
> Jeremy Bauer wrote:
>> You are right, Marina. This also applies to CMC singletons with
>> mixed access. As Carlo points out, one of the primarily goals of EJB
>> 3.x is simplification. By specifying SessionContext is thread safe
>> would be, IMO, consistent with that goal.
>>
>> While is isn't clear from the JPA spec, injected container managed
>> JPA EM's are implicitly thread safe since they are per-transaction.
>> This applies to servlets as well as EJBs. However, use of a "stored"
>> application managed EM is not thread safe. I think this should be
>> clarified in the JPA spec. I'll contact our rep to pursue with the
>> JPA EG...
>>
>> -Jeremy
>>
>>
>>
>> From: Carlo de Wolf <cdewolf_at_redhat.com>
>> To: marina.vatkina_at_oracle.com,
>> Cc: jsr345-experts_at_ejb-spec.java.net
>> Date: 09/05/2012 03:34 AM
>> Subject: [jsr345-experts] Re: [ejb-spec users] [Fwd: Section
>> 16.15.2 question: is SessionContext obligated to be threadsafe?]
>> ------------------------------------------------------------------------
>>
>>
>>
>> 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
>> >
>>
>>