SEAM session or conversational scoped bean?

Question

I am a little confused about which scope to use on my stateful backing bean, I currently have a bean that delivers users results into an xhtml page via JSF, the bean uses the default (conversation scope), with the @Create method marked as @Begin(join=true)....this should make the bean to join the currently long-running conversation, right?

But what I am finding is that when the user navigates to a different page, then back again, the @Create method is being called again on the backing bean, which I want to avoid

The only way around this I have found is to mark the bean as @Scope(ScopeType.SESSION) which maintains the bean for the life of the user login session (as expected).

But having read a few times in the SEAM documentation that it is bad practice to use session scoped backing beans in this way...my questions is, how do I stop the conversational scoped bean from reseting each time the page is reloaded...I feel like I am missing something fundamental about the conversation scope??! Can someone enlighten me please

I have included an edited version of the bean in question below...

@Stateful
@Scope(ScopeType.CONVERSATION)
@Name("sessionActions")
@Restrict("#{identity.isLoggedIn()}")
public class SessionActionsBean implements SessionActions, Serializable {

/**
 * 
 */
private static final long serialVersionUID = 1L;

@Logger private Log log;

@RequestParameter private String sId;
@In Redirect redirect;
@In private MessagePoster messagePoster;
@In private Map<String, String> messages;


@Create
@Begin(join=true)
@Override
public void create(){
        log.debug("bean is being created")
    }

//--------------------------- Cleanup methods
@Remove
@BypassInterceptors
@Override
public void cleanUp(){}

}

Answer 1

Your bean get recreated each time because when you go back to that page you probably have a new conversation.

If you need to keep the conversation open you should look at the conversation propagation mechanisms during navigation.

However there is nothing wrong in having the bean recreated each time, if that's what the logic requires. If you are concerned about performances, don't do preventive assumptions about objects creation before a proper profiling.

If your @Create and @Remove methods manage resources that have a scope broader than conversation, you should separate your conversation scoped bean from another session scoped bean managing that resources.

It's a quite abstract reasoning, but I hope it could help.