Hi Scott,
Class A is annotated with @Stateless in the example, though I do not see any difference it being @Stateful. This is not the case of persistence context propagation/inheritance where it would matter. Real life implementation would of course use CDI scopes like @ConversationScoped (on EntityManagerHolder) and @RequestScoped (on class A). Since this is not CDI specific (but JPA/EJB integration), I skipped CDI annotations.
Also this is not the question whether Hibernate/JBoss support this scenario (I stumbled upon OpenEJB not supporting this), but question whether this is not portable per JPA specification, and where in specification it is told so.
Regards,
Donatas
-----Original Message-----
From: Scott Marlow [mailto:smarlow_at_redhat.com]
Sent: Tuesday, January 29, 2013 7:48 PM
To: users_at_jpa-spec.java.net
Cc: Donatas Čiukšys
Subject: [jpa-spec users] Re: Is it allowed for SFSB to return extended EntityManager to clients?
On 01/29/2013 11:47 AM, Donatas Čiukšys wrote:
> Hi Christian, Arne,
>
> Small code example to illustrate the issue:
>
> ------------------------------------------------------------
>
> @Stateful
>
> public class EntityManagerHolder implements Serializable {
>
> @PersistenceContext(type=PersistenceContextType.EXTENDED) private
> EntityManager em;
>
> public EntityManager getEntityManager() { return em; }
>
> }
>
Is class A stateful in your app?
Which version of AS7 exactly are you using?
Have you tried to recreate against the latest JBoss AS nightly build
http://community.jboss.org/thread/167590?
Also, general questions about JBoss AS can also be raised on
https://community.jboss.org/en/jbossas7.
Regards,
Scott
> @Stateless
>
> public class A {
>
> private EntityManager em;
>
> @EJB private EntityManagerHolder entityManagerHolder;
>
> @PostConstruct
>
> public void construct() {
>
> this.em = entityManagerHolder.getEntityManager();
>
> }
>
> public void testEMaccess() {
>
> entityManagerHolder.getEntityManager().persist(...); // <--
> WORKING OK
>
> em.persist(...); // <-- NOT WORKING
>
> }
>
> }
>
> ------------------------------------------------------------
>
> As noted in method testEMaccess() comments, one line is working, other
> is not (in OpenEJB; in GlassFish both lines are working).
>
> Note that both lines are very similar, and most programmers would be
> tended to get rid of repeated “entityManagerHolder.getEntityManager()”
> calls by storing em in class field (as shown in the second sentence).
>
> Donatas
>
> *From:*Christian von Kutzleben [mailto:cvkutzleben_at_versant.com]
> *Sent:* Tuesday, January 29, 2013 5:29 PM
> *To:* users_at_jpa-spec.java.net
> *Subject:* [jpa-spec users] Re: Is it allowed for SFSB to return
> extended EntityManager to clients?
>
> Hi Donatas
>
> Well I wish they would be the same :) I actually encountered a case
> when EJB container treats them differently. My EJB component (with
> @PersistenceContext annotation) has method: getEntityManager().
> Other EJB components use this method successfully unless the
> PersistenceContext is of extended type (Apache OpenEJB case).
>
>
> The injected proxy is not exactly the same as the real persistence
> context; the injected proxy might be different (that's up to the
> container), but
> eventually the persistence context implementation is the same.
>
> The question could be put this way: must SFSB component (governing
> extended EM) be present in call stack if that EntityManager is
> accessed? Could the answer make it to JPA specificaition?
>
>
> I would assume so for a portable application.
>
> Christian
>
> Donatas
>
> *From:*Christian von Kutzleben [mailto:cvkutzleben_at_versant.com
> <mailto:cvkutzleben_at_versant.com>]
> *Sent:* Tuesday, January 29, 2013 3:22 PM
>
>
> *To:* users_at_jpa-spec.java.net <mailto:users_at_jpa-spec.java.net>
> *Subject:* [jpa-spec users] Re: Is it allowed for SFSB to return
> extended EntityManager to clients?
>
> Hi Donatas,
>
> Although I can not actually answer your question, because I'm just
> looking through the JPA and not the EJB or CDI goggles,
> I have the feeling - maybe I'm wrong - that there is a slight
> misconception about the nature of "extended" vs. "non-extended"
> persistence contexts:
>
> As a JPA/EJB user you might easily get the impression, that those
> are two different things, but actually, they are not:
>
> It is how the container handles a persistence context, which makes
> the difference, it's not inherent in the actually created
> EntityManager instance of the JPA provider. This means, we, as the
> JPA vendor, don't know at all whether a persistence
> context we create and which is used by the container and the
> application is used as extended or non-extended persistence context.
>
> This in turn means, there is no custom way to create an extended
> persistence context, except through the container itself.
> (Not sure, whether this would be a requirement for the CDI producer
> you mentioned or not.)
>
> Christian
>
> On Tue, Jan 29, 2013 at 1:57 PM, Donatas Čiukšys
> <donatas.ciuksys_at_mif.vu.lt <mailto:donatas.ciuksys_at_mif.vu.lt>> wrote:
>
> Hi Christian,
>
> Original question is about single VM, single EJB container,
> multiple EJB beans implementing singe use-case.
>
> Imagine, we’d like to implement somewhat complex use-case (maybe
> even conversation alike), and single EJB component is too
> coarse-grained (low cohesion). We would naturally like to split
> it to several components. One of them is SFSB with extended
> persistence context, others just want to access this entity
> manager.
>
> Of course, there is a way to implement this using persistence
> context propagation. But the limitation is that this SFSB must
> always be the first in the call chain, so it must contain all
> the methods of use-case, though most of them will just delegate
> to other components. This does not sound lean.
>
> CDI allows us to inject “things”, and provides opportunity to
> simplify this call chain. If it would be legal for SFSB to have
> a CDI producer returning extended EntityManager, use-case
> implementation could be simplified. JSF page could directly
> invoke stateless business components. Glassfish supports such a
> producers, the questions is, is it legal per EJB/JPA
> specification, or is it explicitly forbidden.
>
> Just for comparison: it seems that transactional EntityManager
> can be provided to other EJB/CDI components (CDI spec even has
> examples), and all EJB implementations support it. Why extended
> EntityManager is different?
>
> Donatas
>
> *From:*Christian von Kutzleben [mailto:cvkutzleben_at_versant.com
> <mailto:cvkutzleben_at_versant.com>]
> *Sent:* Tuesday, January 29, 2013 2:09 PM
> *To:* users_at_jpa-spec.java.net <mailto:users_at_jpa-spec.java.net>
> *Subject:* [jpa-spec users] Re: Is it allowed for SFSB to return
> extended EntityManager to clients?
>
> Hi Arne,
>
> For a container-managed persistence context, it is expected that
> the container injects a proxy EntityManager instance.
>
> This proxy might contain application-server specific logic (e.g.
> keeping track of the "close" events, if various
> proxies target the same real EM instance).
>
> Because this is not forbidden by the EJB or JPA spec and up to
> the app-server vendor,
> I would presume, that this is of course not supported, because
> manipulating the proxy outside
> the app-server could break the logic assumed by the app-server.
>
> Christian
>
> On Tue, Jan 29, 2013 at 12:54 PM, Arne Limburg
> <arne.limburg_at_openknowledge.de
> <mailto:arne.limburg_at_openknowledge.de>> wrote:
>
> Hi Christian,
>
> I am not talking about clients in another VM, of course this
> is not supported since the EntityManager is not defined to
> be Serializable.
>
> We are just talking about local clients here, like JSF
> managed beans or CDI beans.
>
> Regards,
>
> Arne
>
> *Von: *Christian von Kutzleben <cvkutzleben_at_versant.com
> <mailto:cvkutzleben_at_versant.com>>
> *Antworten an: *"users_at_jpa-spec.java.net
> <mailto:users_at_jpa-spec.java.net>" <users_at_jpa-spec.java.net
> <mailto:users_at_jpa-spec.java.net>>
> *Datum: *Dienstag, 29. Januar 2013 12:49
> *An: *"users_at_jpa-spec.java.net
> <mailto:users_at_jpa-spec.java.net>" <users_at_jpa-spec.java.net
> <mailto:users_at_jpa-spec.java.net>>
> *Betreff: *[jpa-spec users] Re: Is it allowed for SFSB to
> return extended EntityManager to clients?
>
> Hi Arne and Donatas,
>
> Just my 2 cents regardings this:
>
> The general case is, that the client is in another VM.
>
> This in turn would required remoting concepts wrt. to the
> EntityManager, as e.g. an RMI proxy instance would be needed,
> so that the actual requests really happen in the same context.
>
> It seems not to be viable, to actually serialize the whole
> context to any client,
> because the context would exist twice then, and some
> resources hold by the context might not be transferable at all.
> (e.g. a JDBC connection). This leaves a remote proxy as only
> workable approach, and giving the lack of
> any discussion of this aspect in the spec, I doubt whether
> this scenario was ever intended.
>
> Personally I do also dislike this approach because it tends
> to break the layering of an application.
>
> Christian
>
> P.S. in our JDO product we had a feature once - which was
> dropped later - to have remote PersistenceManagers
>
> On Tue, Jan 29, 2013 at 11:02 AM, Arne Limburg
> <arne.limburg_at_openknowledge.de
> <mailto:arne.limburg_at_openknowledge.de>> wrote:
>
> Hi all,
>
>
> Good issue from Donatas. I stumbled over this, too, some
> time ago and I
> would like to extend the question:
> When an entity was loaded from an extended persistence
> context that is
> bound to a stateful session bean. Is lazy loading
> supposed to work outside
> of the call stack of that stateful session bean, i.e. in
> a JSF managed
> bean or a cdi bean that is directly accessed via EL?
> I think it was Jboss AS 7 with Hibernate where this did
> not work.
>
> Regards,
> Arne
>
> Am 29.01.13 10:56 schrieb "donatas.ciuksys_at_mif.vu.lt
> <mailto:donatas.ciuksys_at_mif.vu.lt>" unter
> <donatas.ciuksys_at_mif.vu.lt
> <mailto:donatas.ciuksys_at_mif.vu.lt>>:
>
>
> >Dear JPA experts,
> >
> >Could you please clarify, whether it is allowed for stateful session
> >bean having container-managed extended persistence context to return
> >
> >its EntityManager to clients (and for clients to perform operations on
> >this EntityManager), or is it forbidden?
> >
> >Currently, GlassFish allows returning the extended EntityManager to
> >outside (e.g.http://java.net/jira/browse/GLASSFISH-11805), Apache
> >OpenEJB does not, and there is currently ongoing discussion about issue
> >https://issues.apache.org/jira/browse/TOMEE-509 .
> >
> >JPA 2.0 specification had following text (stars added by me):
> >
> >-----------------------------------------------
> >3.3 Persistence Context Lifetime
> >...
> >When an extended persistence context is used, the extended persistence
> >context exists from the time the
> >EntityManager instance is created until it is closed. This persistence
> >context might span multiple transactions
> >and non-transactional invocations of the EntityManager. A
> >container-managed extended persistence
> >context is enlisted in the current transaction when *the EntityManager
> >is invoked in the scope of
> >that transaction* or when the stateful session bean to which the
> >extended persistence context is bound is
> >invoked in the scope of that transaction.
> >-----------------------------------------------
> >
> >The part between ³*² seems to suggest, that EntityManager could be
> >accessed by some external entity directly, not necessarily through
> >
> >stateful session bean method.
> >I cannot find this text in JPA 2.1 public draft though.
> >
> >Question: can reference to extended EntityManager be provided to
> >outside, and methods called on this reference?
> >
> >Regards,
> >Donatas
>
>
>
>
> --
> Christian von Kutzleben
> Chief Engineer | Versant GmbH
> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
> www.versant.com <http://www.versant.com> | www.db4o.com
> <http://www.db4o.com>
>
> --
> Versant
> GmbH is incorporated in Germany. Company registration
> number: HRB
> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42,
> 22359
> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>
> CONFIDENTIALITY
> NOTICE: This e-mail message, including any attachments, is
> for the sole
> use of the intended recipient(s) and may contain confidential or
> proprietary information. Any unauthorized review, use,
> disclosure or
> distribution is prohibited. If you are not the intended
> recipient,
> immediately contact the sender by reply e-mail and destroy
> all copies of
> the original message.
>
>
>
>
> --
> Christian von Kutzleben
> Chief Engineer | Versant GmbH
> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
> www.versant.com <http://www.versant.com> | www.db4o.com
> <http://www.db4o.com>
>
> --
> Versant
> GmbH is incorporated in Germany. Company registration number: HRB
> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>
> CONFIDENTIALITY
> NOTICE: This e-mail message, including any attachments, is for
> the sole
> use of the intended recipient(s) and may contain confidential or
> proprietary information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> immediately contact the sender by reply e-mail and destroy all
> copies of
> the original message.
>
>
>
>
> --
> Christian von Kutzleben
> Chief Engineer | Versant GmbH
> (T) +49 40 60990-0 <tel:%2B49%2040%2060990-0>
> (F) +49 40 60990-113 <tel:%2B49%2040%2060990-113>
> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
> www.versant.com <http://www.versant.com> | www.db4o.com
> <http://www.db4o.com>
>
> --
> Versant
> GmbH is incorporated in Germany. Company registration number: HRB
> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>
> CONFIDENTIALITY
> NOTICE: This e-mail message, including any attachments, is for the sole
> use of the intended recipient(s) and may contain confidential or
> proprietary information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> immediately contact the sender by reply e-mail and destroy all copies of
> the original message.
>
>
>
>
> --
> Christian von Kutzleben
> Chief Engineer | Versant GmbH
> (T) +49 40 60990-0
> (F) +49 40 60990-113
> (E) cvkutzleben_at_versant.com <mailto:cromberg_at_versant.com>
> www.versant.com <http://www.versant.com> | www.db4o.com
> <http://www.db4o.com>
>
> --
> Versant
> GmbH is incorporated in Germany. Company registration number: HRB
> 54723, Amtsgericht Hamburg. Registered Office: Halenreie 42, 22359
> Hamburg, Germany. Geschäftsführer: Bernhard Wöbker, Volker John
>
> CONFIDENTIALITY
> NOTICE: This e-mail message, including any attachments, is for the sole
> use of the intended recipient(s) and may contain confidential or
> proprietary information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> immediately contact the sender by reply e-mail and destroy all copies of
> the original message.
>