When to use @Begin(join=true)

[dengyin2000]

I have an application which start a new conversation like hibernate hotel booking example. It works fine with one user online. However, if there are more than one user using the application, it will occasionally happen an exception says:

begin method invoked from a long-running conversation, try using @Begin(join=true) on method: selectSnackShop

I have tried use

@Begin(join=true)

, it doesn't have this problem.

/**
    * If false (the default), invocation of the begin
    * method in the scope of an existing conversation
    * will cause an exception to be thrown.
    */
   boolean join() default false;

So, I think whether the hibernate hotel booking example have the same problem.

If a user select a hotel(it start a conversation), however it click a back button, and then select another hotel. So there is an conversation existed and the problem happen? I have tried this. but don't seen the problem.

So when to use

@Begin(join=true)

instead of

@Begin

.

[sleroux]

Hi,

First of all, I'm absolutely not a Seam expert! But I'm sure that if I say something wrong someone more proficient than me will pinpoint it!

So, as I have understood it, @Begin does not create a conversation. The conversation already exists as a temporary conversation. The @Begin annotation just promote this temporary conversation to a long-running one.

(1) When the user performs an action that call an @Begin annotated method the temporary conversation created to handle this action is promoted to a long-running conversation.
(2) Then the user press the back button of its browser. Depending on various things, the browser either show the page in cache or reload the page from the server. In the latter case, there's no conversation-related problem as long as you don't call any @Begin method.
(3) So the user is back to the first page. By its action, it triggers a second call to a @Begin annotated method (for example: it change its mind and select an other hotel). Now, there is a problem: there is already a long running conversation in progress. The one created on (1).

As you noticed @Begin(join=true) solve this problem:

• If no long-running conversation is in progress (like in (1)), @Begin(join=true) behave just as @Begin


• If there is a long-running conversation in progress (like in (3)) @Begin(join=true) just do nothing (?) or at least re-use the existing long-running conversation.

Well, maybe the real (at least for me) question is when is it safe to call @Begin instead of @Begin(join=true)?

Hope this will help,
Sylvain

[dengyin2000]

Thanks, Sylvain

I agree that the temporary conversation will promote to a long-running conversation if it invokes a method with @Begin annotation. If it invokes a method with @End annotation, the current long-running conversation will turn to a temporary conversation again .

In fact, the browser's back button can't cause the problem, yes, I have tried, I just don't know How to reproduce this problem. Because the problem happens occasionally, and only occur when there are more than one user operating. I don't know whether this is a seam's bug. If it is, it seems you should replace all @Begin with

@Begin(join=true)

.

I am a newbie of Seam, The way of beginning a conversation is straight copying from hibernate hotel booking example. So I think the hibernate hotel booking example has the same problem. Any feedback is appreciated.

[toni]

Hi deng, it most likely has nothing to do with the amount of users, because each conversation is isolated from other users.

But the more users you have the more likely it is that some unlikely user navigation will cause the error.

[dengyin2000]

I know, seam conversations definitely sit at http sessions. So the conversations are isolated for each other. Can you explain more clearly how user navigation will cause the error? Thanks.

[rvdwalt]

Ok, we also get this problem and have isolated a sequence of events that replicate it every time. Our system that we are developing gets served over the internet and at times due to location or whatever the response from the webserver is slow. Thus the users tend to think that the 'button' has been misclicked or not read and click the button again.
i.e. Say the add button gets pressed for a second time before the response of the first button gets shown to the user. What we need is either a way to tell seem to ignore button presses from the same source in x amount of time or a way to join the conversation without it calling the method annotated with @Begin.