Christian von Kutzleben <cvkutzleben_at_versant.com> wrote on 07/01/2013
02:49:32 AM:
>
> Hi Kevin,
>
> E.g. object navigation accesses and modifies the internal structures
> that make up the object context through
> internal interfaces (that are vendor specific) and you can't protect
> these interfaces by having a thread-safe EM proxy.
>
> Christian
Hi Christian,
Sure, I agree. But, we have the same issue with EM injection into
stateless session beans and that's part of the spec. We would also have
the issue if an application attempted to share an EM across multiple
threads. The detection and/or prevention of "bad usage patterns" is an
exercise left up to the jpa providers.
Are you advocating that we remove the ability to inject EM's altogether?
The spec is very clear that EM's are not thread-safe. But, the spec is
not clear on whether injected EM's are safe to use in a Servlet. I'm
stating that we need to clarify this usage pattern. Either this is
considered a safe operation (to the extent of the spec-defined
capabilities), or it is not allowed. But, as it stands today, there is
missing information and each vendor is free to describe the interpretation
and level of support.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
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/
Christian von Kutzleben <cvkutzleben_at_versant.com> wrote on 07/01/2013
02:49:32 AM:
> From: Christian von Kutzleben <cvkutzleben_at_versant.com>
> To: jsr338-experts_at_jpa-spec.java.net,
> Cc: Scott Marlow <smarlow_at_redhat.com>
> Date: 07/01/2013 02:50 AM
> Subject: [jsr338-experts] Re: [jpa-spec users] Re: Thread safety for
> injected EMs
>
> Hi Kevin,
>
> E.g. object navigation accesses and modifies the internal structures
> that make up the object context through
> internal interfaces (that are vendor specific) and you can't protect
> these interfaces by having a thread-safe EM proxy.
>
> Christian
> On Thu, Jun 27, 2013 at 5:09 PM, Kevin Sutter <sutter_at_us.ibm.com> wrote:
> > If the container injected proxies were thread-safe, this just would
> > not be sufficient to protect the internal structures
> > of the persistence context implementation.
> But, isn't this the approach that is used by containers to ensure
> the injected EMs into Stateless Session Beans are "thread safe"?
> Either that, or the container ensures that unique instances are
> created for each injection. So, as long as the container is
> properly managing these injected instances, why can't we indicate/
> declare that use of injected EMs in Servlets is a safe practice?
>
>
----------------------------------------------------------------------------------------------------------------------------------------------------------------
> 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/
>
> Christian von Kutzleben <cvkutzleben_at_versant.com> wrote on 06/27/
> 2013 08:41:41 AM:
>
> > From: Christian von Kutzleben <cvkutzleben_at_versant.com>
> > To: Scott Marlow <smarlow_at_redhat.com>,
> > Cc: jsr338-experts_at_jpa-spec.java.net, Kevin Sutter/Rochester/IBM_at_IBMUS
> > Date: 06/27/2013 08:42 AM
> > Subject: Re: [jsr338-experts] Re: [jpa-spec users] Re: Thread safety
> > for injected EMs
> >
> > Hi Scott,
> >
> > My point is: if it does not work at all at a conceptual level, it
> > does not make sense to introduce such a feature.
> >
> > If the container injected proxies were thread-safe, this just would
> > not be sufficient to protect the internal structures
> > of the persistence context implementation.
> >
> > Christian
>
> > On Thu, Jun 27, 2013 at 3:14 PM, Scott Marlow <smarlow_at_redhat.com>
wrote:
> > 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.
>
> >
> >
> >
> >
> > --
> > Christian von Kutzleben
> > Chief Software Engineer
> > Versant GmbH, Subsidiary of Actian Corporation
> > christian.vonkutzleben_at_actian.com
> > PHONE +49 40 60990-273
> > FAX +49 40 60990-113
> > 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
> > [image removed] [image removed] [image removed] [image removed]
> > [image removed]
> > [image removed]
> > 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.
>
>
>
> --
> Christian von Kutzleben
> Chief Software Engineer
> Versant GmbH, Subsidiary of Actian Corporation
> christian.vonkutzleben_at_actian.com
> PHONE +49 40 60990-273
> FAX +49 40 60990-113
> 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
> [image removed] [image removed] [image removed] [image removed]
> [image removed]
> [image removed]
> 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.