Skip to main content

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

  • From: Arne Limburg <arne.limburg@...>
  • To: "users@..." <users@...>
  • Subject: [jpa-spec users] Re: Is it allowed for SFSB to return extended EntityManager to clients?
  • Date: Tue, 29 Jan 2013 15:12:56 +0000
  • Accept-language: de-DE, en-US

Hi Christian,

What you write is not right: You write that "there is no custom way to create an extended persistence context, except through the container itself." But Chapter 7.7 states about application-managed persistence context that they are "extended in scope". So in fact EVERY EntityManager we create manually is extended.

But that is not the point of Donatas and me: Donatas point is: You can always take an EntityManager that was injected by the Container and pass it around (to another EJB or even outside an EJB). The question is: Is it supposed to work outside that EJB it was injected into? And my additional question is: Is lazy loading of entities from an extended EntityManager supposed to work outside that EJB.

Regards,
Arne

Von: Christian von Kutzleben <cvkutzleben@...>
Antworten an: "users@..." <users@...>
Datum: Dienstag, 29. Januar 2013 14:21
An: "users@..." <users@...>
Betreff: [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@...> 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@...]
Sent: Tuesday, January 29, 2013 2:09 PM
To: users@...
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@...> 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@...>
Antworten an: "users@..." <users@...>
Datum: Dienstag, 29. Januar 2013 12:49
An: "users@..." <users@...>
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@...> 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@..." unter
<donatas.ciuksys@...>:


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


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

donatas.ciuksys 01/29/2013

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

Arne Limburg 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Arne Limburg 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Donatas Čiukšys 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Arne Limburg 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Arne Limburg 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Donatas Čiukšys 01/29/2013

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

Christian von Kutzleben 01/29/2013

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

Donatas Čiukšys 01/29/2013

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

Scott Marlow 01/29/2013

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

Donatas Čiukšys 01/30/2013
 
 
Close
loading
Please Confirm
Close