users@jpa-spec.java.net

[jpa-spec users] Re: Is it allowed for SFSB to return extended EntityManager to clients?

From: Christian von Kutzleben <cvkutzleben_at_versant.com>
Date: Tue, 29 Jan 2013 14:21:31 +0100

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>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]
> *Sent:* Tuesday, January 29, 2013 2:09 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 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> 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>
> *Antworten an: *"users_at_jpa-spec.java.net" <users_at_jpa-spec.java.net>
> *Datum: *Dienstag, 29. Januar 2013 12:49
> *An: *"users_at_jpa-spec.java.net" <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> 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" unter
> <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
> (F) +49 40 60990-113
> (E) cvkutzleben_at_versant.com <cromberg_at_versant.com>
> www.versant.com | 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 <cromberg_at_versant.com>
> www.versant.com | 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 <cromberg_at_versant.com>
www.versant.com | 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.