users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: Re: Thread safety for injected EMs

From: Scott Marlow <smarlow_at_redhat.com>
Date: Wed, 26 Jun 2013 14:32:31 -0400

On 06/26/2013 02:01 PM, Scott Marlow wrote:
> On 06/26/2013 12:28 PM, Kevin Sutter wrote:
>> Hi,
>> There seems to be a lot of conflicting information on the web concerning
>> the thread-safety of injected EMs in runtime components. From a
>> WebSphere perspective, our injected EMs are thread-safe regardless of
>> the runtime component -- EJBs or Servlets. But, there are several
>> references that indicate injected EMs in a Servlet are not thread-safe
>> [1, as an example]. Our JPA spec is not clear on this (or, at least I
>> couldn't find a definitive answer). What's the consensus of the group?
>> Should injected EMs in a Servlet be considered thread-safe? Or, is
>> this an implementation detail left up to each application server?
>>
>> I understand that EMs by themselves are not considered thread-safe.
>> We're clear on that aspect in the spec [sec 7.2]. But, when the
>> container is managing the injection of these EMs and the associated
>> transactional context, can we consider these EMs to only be accessed by
>> a single thread? Like I said, WebSphere has controls and processing in
>> place to allow for this usage pattern, but we're not clear whether this
>> is a generally accepted pattern or unique to WebSphere? I think this is
>> pretty clear when a Transactional context is in place -- in this case,
>> the EM should be injectable into a Servlet. But, maybe it becomes more
>> murky when a Transactional context is not defined? Is this where the
>> concern comes from and it now depends on the QoS provided by the
>> application server?
>
> I agree that it becomes murky when a Transactional context is not
> defined. For example, to satisfy an EM invocation, the container could
> use a *cached* underlying entity manager that is obtained from a
> thread-unsafe collection.
>
> Even if containers aren't doing that, they still could. I'm not against
> changing the rules (in a future spec), to not allow such thread-unsafe
> access in containers.

Oops, we have that already today. :)

I'm not against changing the rules (in a future spec), to *specify* that
a container managed entity manager is thread safe but the underlying
entity manager is not.

>
> When we talk about using an *underlying* entity manager in a servlet, I
> think that should still be considered a thread-unsafe object.
>
>>
>> Customers are getting conflicting information from the specs, web
>> references, and jpa provider support... I'm looking for clarification
>> on this usage pattern. If something exists, just point me in the right
>> direction. Otherwise, maybe we can open a JIRA or something to clarify
>> this in the next rev of the spec? Thanks!
>> [1]
>> https://weblogs.java.net/blog/ss141213/archive/2005/12/dont_use_persis_1.html
>>
>>
>>
>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Kevin Sutter, Java EE and Java Persistence API (JPA) architect
>> mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
>> http://webspherepersistence.blogspot.com/
>> phone: tl-553-3620 (office), 507-253-3620 (office)
>> http://openjpa.apache.org/
>