You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@myfaces.apache.org by Carl Howarth <ca...@dlapiper.com> on 2009/02/11 11:55:35 UTC

orchestra/datatable/datascroller LazyInitializationException

Hi all,

I am having my first look into Orchestra 1.2 in my MyFaces 1.2.3/Facelets,
Spring 2.5.6, JPA, Hibernate app and am having difficulties.

In a nutshell I have the following:

searchparameters.xhtml - users enter various search parameters into a form
and hit 'search'. This calls an action that calls a search method of a
service bean defined in spring (which in turn calls a DAO bean also defined
in spring). The service bean's method is marked as @Transactional(readOnly =
true). The results set is a List returned from Hibernate with various LAZY
collections. If results are returned the list is passed through to the
'SearchResultsBean' which is in turn bound to a rich:datatable on
searchresults.xhtml.

I have tried wiring up both backing beans with conversation.access scope:

Before orchestra, all collections were EAGERly fetched and the results set
was kept alive in the search results bean using a <t:saveState /> tag.

The first page displays successfully, but when I try to use a
rich:datascroller to scroll to another page I get the
LazyInitializationException. Clearly I have missed something and hopefully
somebody out there will be able to point me in the right direction! I was
under the impression that conversation.access did not require me to
start/name conversations manually.

Can anyone help?

Thanks very much in anticipation, Carl

--
View this message in context: http://www.nabble.com/orchestra-datatable-datascroller-LazyInitializationException-tp21952429p21952429.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

RE: orchestra/datatable/datascroller LazyInitializationException

Posted by Carl Howarth <ca...@dlapiper.com>.

Hello there,

I have removed the savestate but to no avail. I presume I need to be somehow
share the conversation  between the parameters and results beans but am
unsure how to go about it. So in effect I am not passing just one result, I
am passing the whole resultset from the parameters page to the results page
through which the conversation needs to live.

I hope this makes sense! 

Thanks, Carl


Mario Ivankovits wrote:
> 
> Hi!
>> -----Original Message-----
>> From: Carl Howarth [mailto:carl.howarth@dlapiper.com]
>> Sent: Wednesday, February 11, 2009 11:56 AM
> 
>>   <bean name="searchParametersBean"
>> class="com.xxx.SearchParametersBean"
>> scope="conversation.access">
>>     <property name="serviceBean" ref="serviceBean" />
>>     <property name="searchResultsBean" ref="searchResultsBean" />
>>   </bean>
>> 
>>   <bean name="searchResultsBean" class="com.xxx.SearchResultsBean"
>> scope="conversation.access"/>
>> 
>> Before orchestra, all collections were EAGERly fetched and the results
>> set
>> was kept alive in the search results bean using a <t:saveState /> tag.
> 
> Do you still use t:saveState too? Just in case, this should not be
> required .. nor used as then the entity is detached.
> Also, when passing back the result, just pass back the primary key and
> reload the entity from the result bean. An entity from another
> conversation is detached once the conversation is invalidated/not accessed
> anymore, thus reload the entity in the target conversation to have it
> associated with the right EntityManager/PersistenceContext.
> 
> Ciao,
> Mario
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/orchestra-datatable-datascroller-LazyInitializationException-tp21952429p21953552.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: orchestra/datatable/datascroller LazyInitializationException

Posted by Simon Kitching <sk...@apache.org>.

Mario Ivankovits schrieb:
> Hi!
>> -----Original Message-----
>> From: Carl Howarth [mailto:carl.howarth@dlapiper.com]
>> Sent: Wednesday, February 11, 2009 11:56 AM
> 
>>   <bean name="searchParametersBean"
>> class="com.xxx.SearchParametersBean"
>> scope="conversation.access">
>>     <property name="serviceBean" ref="serviceBean" />
>>     <property name="searchResultsBean" ref="searchResultsBean" />
>>   </bean>
>>
>>   <bean name="searchResultsBean" class="com.xxx.SearchResultsBean"
>> scope="conversation.access"/>
>>
>> Before orchestra, all collections were EAGERly fetched and the results
>> set
>> was kept alive in the search results bean using a <t:saveState /> tag.
> 
> Do you still use t:saveState too? Just in case, this should not be required .. nor used as then the entity is detached.
> Also, when passing back the result, just pass back the primary key and reload the entity from the result bean. An entity from another conversation is detached once the conversation is invalidated/not accessed anymore, thus reload the entity in the target conversation to have it associated with the right EntityManager/PersistenceContext.
> 

Ah yes. As Mario says, two beans that are in different conversations
cannot pass entity beans between themselves, because the different
conversations have different sessions, and a bean loaded from one
session cannot be used in a different session.

One solution (as Mario noted) is to just pass the key between the two
backing beans, and have the "detail" bean reload the entity using its
own persistence session.

The other approach is to put both beans in the same conversation, by
setting the conversationName property on the bean declarations. The
disadvantage here is that when you re-enter the detail page for a second
time, the backing bean is *not* recreated, because the conversation it
was in has not been deleted. So probably passing by key is the best
solution.

Regards, Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)

RE: orchestra/datatable/datascroller LazyInitializationException

Posted by Mario Ivankovits <ma...@ops.co.at>.

Hi!
> -----Original Message-----
> From: Carl Howarth [mailto:carl.howarth@dlapiper.com]
> Sent: Wednesday, February 11, 2009 11:56 AM

>   <bean name="searchParametersBean"
> class="com.xxx.SearchParametersBean"
> scope="conversation.access">
>     <property name="serviceBean" ref="serviceBean" />
>     <property name="searchResultsBean" ref="searchResultsBean" />
>   </bean>
> 
>   <bean name="searchResultsBean" class="com.xxx.SearchResultsBean"
> scope="conversation.access"/>
> 
> Before orchestra, all collections were EAGERly fetched and the results
> set
> was kept alive in the search results bean using a <t:saveState /> tag.

Do you still use t:saveState too? Just in case, this should not be required .. nor used as then the entity is detached.
Also, when passing back the result, just pass back the primary key and reload the entity from the result bean. An entity from another conversation is detached once the conversation is invalidated/not accessed anymore, thus reload the entity in the target conversation to have it associated with the right EntityManager/PersistenceContext.

Ciao,
Mario