myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: orchestra/datatable/datascroller LazyInitializationException
Date Wed, 11 Feb 2009 12:16:40 GMT
Mario Ivankovits schrieb:
> Hi!
>> -----Original Message-----
>> From: Carl Howarth []
>> Sent: Wednesday, February 11, 2009 11:56 AM
>>   <bean name="searchParametersBean"
>> class=""
>> scope="conversation.access">
>>     <property name="serviceBean" ref="serviceBean" />
>>     <property name="searchResultsBean" ref="searchResultsBean" />
>>   </bean>
>>   <bean name="searchResultsBean" class=""
>> 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

Regards, Simon

-- Emails in "mixed" posting style will be ignored
-- (

View raw message