On 7/2/2013 11:24 AM, Kevin Sutter wrote:
> Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 07/02/2013 12:07:41 PM:
> >
> > Hi Kevin,
> >
> > I'm afraid I don't see how the stateless session bean analogy applies.
> > Stateless session beans do not support multithreaded use as servlets
> > do.
> >
> Fair enough. I guess I was applying the concept of sharing EMs and the use of vendor-specific interfaces across the
> board. But, that was getting off topic.
>
> > We added the language in Section 7.2 with the intent to cover the servlet
> > multithreaded case.
> >
> > "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. Entity managers must only be accessed
> > in a single-threaded manner."
> >
> Yes, and that's the section that started this whole discussion.
>
> > This is independent of the type of entity manager (i.e., container- or
> > application-managed) or whether it is injected or looked up in JNDI.
> > The reason our tutorials etc. recommend lookup, is because of the limitation
> > of being able to inject into stack variables.
> >
> > IIRC, we added the spec language above as a caution to application developers,
> > (i.e., and not as a prohibition against JPA vendors providing a means of
> > safe multithreaded use).
> >
> Okay. So, your take is that this issue is already sufficient covered by the specification? I can see your viewpoint, but
> since there's no specific citation whether injection into a Servlet is allowed, disallowed, or vendor specific, it still
> seems like a hole. Any chance we could at least open a JIRA for clarification in the next rev of the spec?
>
Sure -- feel free to take the lead on submitting the JIRA issue. We should also discuss standardizing
support for the thread safety of entity managers in servlets as well.
-Linda
> Thanks!
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Kevin Sutter, Java EE and Java Persistence API (JPA) architect
> mail: sutter@us.ibm.com, Kevin Sutter/Rochester/IBM http://webspherepersistence.blogspot.com/
> phone: tl-553-3620 (office), 507-253-3620 (office) http://openjpa.apache.org/
>
>
> Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 07/02/2013 12:07:41 PM:
>
> > From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> > To: jsr338-experts_at_jpa-spec.java.net,
> > Cc: Kevin Sutter/Rochester/IBM_at_IBMUS
> > Date: 07/02/2013 12:08 PM
> > Subject: [jsr338-experts] Re: [jpa-spec users] Re: Thread safety for
> > injected EMs
> >
> > Hi Kevin,
> >
> > I'm afraid I don't see how the stateless session bean analogy applies.
> > Stateless session beans do not support multithreaded use as servlets
> > do.
> >
> > We added the language in Section 7.2 with the intent to cover the servlet
> > multithreaded case.
> >
> > "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. Entity managers must only be accessed
> > in a single-threaded manner."
> >
> > This is independent of the type of entity manager (i.e., container- or
> > application-managed) or whether it is injected or looked up in JNDI.
> > The reason our tutorials etc. recommend lookup, is because of the limitation
> > of being able to inject into stack variables.
> >
> > IIRC, we added the spec language above as a caution to application developers,
> > (i.e., and not as a prohibition against JPA vendors providing a means of
> > safe multithreaded use).
> >
> >
> > -Linda
> >
> >
> > On 7/2/2013 8:02 AM, Kevin Sutter wrote:
> > > 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 theuse 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.
> >