jsr338-experts@jpa-spec.java.net

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

From: Scott Marlow <smarlow_at_redhat.com>
Date: Thu, 27 Jun 2013 09:14:57 -0400

On 06/27/2013 04:10 AM, Christian von Kutzleben wrote:
> Hi Kevin,
>
>
> 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?
>
>
> The injected instance implementing EntityManager could of course be made
> thread-safe,
> however, this only synchronizes threads accessing the underlying
> persistence context through
> the EntityManager interface and threads, accessing the persistence
> context otherwise would
> corrupt the data (specifically: field/property access of instances,
> which cause delayed/lazy loading)

Christian,

IMO, this discussion is only for the container managed entity manager
that is injected. If we all agree here, in a future spec, the container
managed entity manager can be required to be thread-safe. The
underlying entity manager that is used for each entity manager
invocation, is not required to be thread-safe.

If you implement a persistence provider, you can continue to enjoy
(mostly) not worrying about thread safety. Providers do need to handle
at least one concurrency case (in your tx sync callback), you should
handle transaction rollbacks from a background thread. From section JPA
2.1 7.9.2:

"
When the JTA transaction rolls back, the provider must detach all
managed entities if the persistence context is of type
SynchronizationType.SYNCHRONIZED or has otherwise been joined to the
transaction. Note that the JTA transaction may rollback in a background
thread (e.g., as a result of transaction timeout), in which case the
provider should arrange for the managed entities to be detached from the
persistence context but not concurrently while the application is in an
EntityManager invocation.
"

Scott

>
> So IMO only the JPA implementation could provide means for
> thread-safety, but this is not a required
> feature, so from my point of view, unless a thread-safe feature would be
> introduced to JPA and the
> "injector" enables this, this can not work at all.
>
> (Personally, I'm in favor of not introducing such a feature; we had that
> in the JDO spec and it just
> creates unnecessary complexity and issues to only support some corner
> usecases)
>
> Christian
>
> --
>
> *Christian von Kutzleben*
> Chief Software Engineer
> Versant GmbH, Subsidiary of Actian Corporation
> christian.vonkutzleben_at_actian.com <mailto:christian.vonkutzleben_at_actian.com>
>
> PHONE +49 40 60990-273
> FAX +49 40 60990-113
> www.actian.com <http://www.actian.com/>
>
> Versant GmbH is incorporated in Germany. Company registration number:
> HRB 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
> Hamburg, Germany. Geschäftsührer: Marc Monahan, Fred Gallagher, Volker John
>
> Facebook-icon <http://www.facebook.com/actiancorp>Twitter-icon
> <http://twitter.com/actiancorp>Linked-In-icon
> <http://www.linkedin.com/company/actian-corporation>You-Tube-icon
> <http://www.youtube.com/actiancorporation>http://davidwalsh.name/dw-content/googleplus-icon.png
> <http://www.gplus.to/actiancorp>
>
> *cid:image001.jpg@01CC7916.C4DCFC40 <http://www.actian.com/>*
>
> This transmission is confidential and intended solely for the use of the
> recipient named above. It may contain confidential, proprietary, or
> legally privileged information. If you are not the intended recipient,
> you are hereby notified that any unauthorized review, use, disclosure or
> distribution is strictly prohibited. If you have received this
> transmission in error, please contact the sender by reply e-mail and
> delete the original transmission and all copies from your system.
>