RE: orchestra/datatable/datascroller LazyInitializationException
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. Ciao, Mario
RE: orchestra/datatable/datascroller LazyInitializationException
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.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. 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
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)
