Mario Ivankovits schrieb: > Hi! >> -----Original Message----- >> From: Carl Howarth [mailto:carl.howa...@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)
