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.
>