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?
Thanks!
----------------------------------------------------------------------------------------------------------------------------------------------------------------
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/
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.
>