Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

I'm currently using Struts2 in a project that is utilizing the Java Persistence
API (JPA, specifically Hibernate) with container managed transactions (CMT).  To
access the Persistence layer, a layer was created using SLSBs as "service"
objects which provide simple "<entity_type> get<entity_type>ById( int )" and
"List<<entity_type>> get<entity_type>s()" type methods.  The Struts2 Actions use
these beans (by injection (provided by some interceptor, such as the EJB3
Plugin) or a JNDI lookup, it doesn't matter really) to get the instances of the
entities.

Up until now, all of the properties of the entities that were being accessed to
create the view were either eagerly fetched associations, or private members of
the entity.  Recently, I have the need to start using lazily fetched
associations (self joins and the like), and need to find a way to extend the
Persistence context through to the view generation.

Although there isn't much need to explain, the error I am receiving is the
following:
ERROR [LazyInitializationException] failed to lazily initialize a collection of
role: <private_member_name>, no session or session was closed

I noticed recently that there was a "Full Hibernate" Plugin that supports
injection of a Session (presumably into an Action?) and will close the Session
after the view generation.  This works fine for application managed persistence,
but does not solve the issue of when using CMT (or at least to my knowledge).

Searching the web for solutions to the problem resulted in a suggestion to
create an interceptor (that runs after the Action, but before the view
generation?) that does a JNDI lookup to create an EntityManager (extending the
Persistence Context to the interceptor, I think).  I'm not sure what this was
supposed to resolve, but I have not tried this as 1) I'm not sure how to create
such an interceptor and get it to "intercept" at the appropriate time, and 2) I
don't think this would resolve anything, as I don't think this would really
extend the Persistence Context through to the view generation.

How are others resolving this issue and using lazy initialization?

I have a few more ideas as last resorts, but I don't want to taint the
responses, so I will hold onto them for now.

Thanks,
-Nate


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

Nathan Schulte <nathan.schulte <at> ngc.com> writes:
> I'll let you know what I come up with.

Well, I was able to get this to work.  The interceptor is placed on the end of
the stack, although it's location oughtn't matter.  Also, it is placed on the
stack for _all_ actions.  I'm not sure if this is a problem, it may actually be
a good thing (at least in my case, I was not wrapping all of the actions' calls
to the EJBs in a UserTransaction, this takes care of that, everywhere).  Also
note, this doesn't support transaction rollback in it's current form.  As a
simple test, it worked though.

This would look ten times prettier if only the container supported resource
injection, :).

http://pastebin.com/f3c76ae6f

-Nate


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

Wes Wannemacher <wesw <at> wantii.com> writes:
> This is not exactly what you want, and it's based on Hibernate and a
> hibernate session, but if you think of hibernate sessions as jpa EMs,
> then you can just make the appropriate changes to this and at least be
> further than you are now.

Thanks Wes, I don't know how I didn't catch that page when browsing the docs. 
That's actually very similar to the interceptor I just started working on.  I'll
let you know what I come up with.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Wes Wannemacher <we...@wantii.com>]

http://struts.apache.org/2.x/docs/non-ioc-version-of-opensessioninviewinterceptor.html

This is not exactly what you want, and it's based on Hibernate and a
hibernate session, but if you think of hibernate sessions as jpa EMs,
then you can just make the appropriate changes to this and at least be
further than you are now.

-Wes

On Fri, Jul 17, 2009 at 3:09 PM, Nathan Schulte<na...@ngc.com> wrote:
> Jim Kiley <jhkiley <at> summa-tech.com> writes:
>> I assume that the OpenEntityManagerInViewFilter is not the solution for you?
>
> I'm not using Spring.  As such, I'm not familiar with this filter, but from the
> description, yes, that is what is needed.  However, the app server manages the
> transactions, and injects the EntityManager when needed.  I can do a JDNI lookup
> and receive an EntityManager, but I'm unsure of where this would actually need
> to be placed (an interceptor? in the action, to be placed on the stack
> somewhere(so a reference is held?)).
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>



-- 
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

Jim Kiley <jhkiley <at> summa-tech.com> writes:
> I assume that the OpenEntityManagerInViewFilter is not the solution for you?

I'm not using Spring.  As such, I'm not familiar with this filter, but from the
description, yes, that is what is needed.  However, the app server manages the
transactions, and injects the EntityManager when needed.  I can do a JDNI lookup
and receive an EntityManager, but I'm unsure of where this would actually need
to be placed (an interceptor? in the action, to be placed on the stack
somewhere(so a reference is held?)).




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Jim Kiley <jh...@summa-tech.com>]

I think I missed the early part of the discussion -- I assume that the
OpenEntityManagerInViewFilter is not the solution for you?
jk

On Fri, Jul 17, 2009 at 2:53 PM, Nathan Schulte <na...@ngc.com>wrote:

> So is this the only resolution out there?  To lazily initialize the
> contents I
> know I'll need before the container decides to trash the persistence
> context?
> There is no way to extend the context such that the lazy initialization
> will
> work when rendering the view?
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


-- 
Jim Kiley
Senior Technical Consultant | Summa
[p] 412.258.3346
http://www.summa-tech.com

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

So is this the only resolution out there?  To lazily initialize the contents I
know I'll need before the container decides to trash the persistence context? 
There is no way to extend the context such that the lazy initialization will
work when rendering the view?





---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[Nathan Schulte <na...@ngc.com>]

David Canos <davidcanos <at> gmail.com> writes:
> I use a Hibernate.initilize() call in the DAO layer for every object I need
> to see in the presentation layer (common jsp files).it avoids Lazy
> Initializations without passing Hibernate Proxy around layers.

This was one of my last resort ideas.  It completely flies in the face of lazy
initialization, by proactively initializing them.  Obviously something I want to
avoid.

There ought to be no need to pass around a hibernate proxy at all, the container
should take care of everything for you, that's the point of CMT.  I know there
has to be a proper solution out there, I just have to wait for the right person
to stumble onto the mailing list.

Thanks for letting me know that this method does indeed work though.  I have not
tested it myself, but at least I know now that not _all_ hope is lost.

-Nate


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Struts2 + JPA - Lazy Initialization During View Generation

[David Canos <da...@gmail.com>]

I use a Hibernate.initilize() call in the DAO layer for every object I need
to see in the presentation layer (common jsp files).it avoids Lazy
Initializations without passing Hibernate Proxy around layers.
It works fine for me


2009/7/15 Nathan Schulte <na...@ngc.com>

> I'm currently using Struts2 in a project that is utilizing the Java
> Persistence
> API (JPA, specifically Hibernate) with container managed transactions
> (CMT).  To
> access the Persistence layer, a layer was created using SLSBs as "service"
> objects which provide simple "<entity_type> get<entity_type>ById( int )"
> and
> "List<<entity_type>> get<entity_type>s()" type methods.  The Struts2
> Actions use
> these beans (by injection (provided by some interceptor, such as the EJB3
> Plugin) or a JNDI lookup, it doesn't matter really) to get the instances of
> the
> entities.
>
> Up until now, all of the properties of the entities that were being
> accessed to
> create the view were either eagerly fetched associations, or private
> members of
> the entity.  Recently, I have the need to start using lazily fetched
> associations (self joins and the like), and need to find a way to extend
> the
> Persistence context through to the view generation.
>
> Although there isn't much need to explain, the error I am receiving is the
> following:
> ERROR [LazyInitializationException] failed to lazily initialize a
> collection of
> role: <private_member_name>, no session or session was closed
>
> I noticed recently that there was a "Full Hibernate" Plugin that supports
> injection of a Session (presumably into an Action?) and will close the
> Session
> after the view generation.  This works fine for application managed
> persistence,
> but does not solve the issue of when using CMT (or at least to my
> knowledge).
>
> Searching the web for solutions to the problem resulted in a suggestion to
> create an interceptor (that runs after the Action, but before the view
> generation?) that does a JNDI lookup to create an EntityManager (extending
> the
> Persistence Context to the interceptor, I think).  I'm not sure what this
> was
> supposed to resolve, but I have not tried this as 1) I'm not sure how to
> create
> such an interceptor and get it to "intercept" at the appropriate time, and
> 2) I
> don't think this would resolve anything, as I don't think this would really
> extend the Persistence Context through to the view generation.
>
> How are others resolving this issue and using lazy initialization?
>
> I have a few more ideas as last resorts, but I don't want to taint the
> responses, so I will hold onto them for now.
>
> Thanks,
> -Nate
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>