Skip to main content

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

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr338-experts@...
  • Subject: [jpa-spec users] [jsr338-experts] Re: Re: Thread safety for injected EMs
  • Date: Tue, 02 Jul 2013 11:38:30 -0700
  • List-id: <jsr338-experts.jpa-spec.java.net>
  • Organization: Oracle Corporation



On 7/2/2013 11:24 AM, Kevin Sutter wrote:
Linda DeMichiel <linda.demichiel@...> 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@..., 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@...> wrote on 07/02/2013 12:07:41 PM:

 > From: Linda DeMichiel <linda.demichiel@...>
 > To: jsr338-experts@...,
 > Cc: Kevin Sutter/Rochester/IBM@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@...> 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@..., 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@...> wrote on 07/01/
 > 2013 02:49:32 AM:
 > >
 > > > From: Christian von Kutzleben <cvkutzleben@...>
 > > > To: jsr338-experts@...,
 > > > Cc: Scott Marlow <smarlow@...>
 > > > 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@...> 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@..., 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@...> wrote on 06/27/
 > > > 2013 08:41:41 AM:
 > > >
 > > > > From: Christian von Kutzleben <cvkutzleben@...>
 > > > > To: Scott Marlow <smarlow@...>,
 > > > > Cc: jsr338-experts@..., Kevin Sutter/Rochester/IBM@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@...> 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@... <
 > mailto:christian.vonkutzleben@...>
 > > > >
 > > > >
 > > > > 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@...
 > > > > 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@...
 > > > 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.
 >


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

Christian von Kutzleben 07/01/2013

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

Kevin Sutter 07/02/2013

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

Linda DeMichiel 07/02/2013

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

Kevin Sutter 07/02/2013

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

Linda DeMichiel 07/02/2013
 
 
Close
loading
Please Confirm
Close