threading and conversations

[gonorrhea]

Seam enforces a single thread per conversation per process model for the conversation context by serializing concurrent requests in the same long-running conversation context. 

http://www.redhat.com/docs/en-US/JBossEnterpriseApplicationPlatform/4.3.0.cp04fp01/html/SeamReferenceGuide/concepts.html

What does the above statement mean exactly?  So what happens if you have two methods that fire precisely at the same time on two different business methods on a SFSB that is conversation-scoped?  Do they each take their turn processing or process simultaneously?  In my debugger it seems that they are running simultaneously...

[swd847]

If they are both trying to run in the the same long running conversation then they will be run one after the other (i.e. if they are both trying to run on the same instance of the conversation scoped bean).

If they are try to run in two separate conversations there are two instances of the bean and they run concurrently.

[gonorrhea]

I'm more concerned with the former situation.

So two near-simultaneous method calls via action handlers in the same xhtml/JSF to the same SFSB instance constitutes a single thread or two threads?

I always thought that there was a 1:1 ratio b/n HTTP request and a thread in the server/JVM.  Is this correct?

In the Eclipse debugger I am not seeing an extra thread being spawned...

And what if the use case actually requires two simultaneous method calls to the same SFSB?  Then what?  You change the scope of the comopnent from conversation to session?

When I tried that there was an exception requiring @Synchronized for my SFSB.

[swd847]

Arbi Sookazian wrote on May 20, 2009 06:18:


I'm more concerned with the former situation.

So two near-simultaneous method calls via action handlers in the same xhtml/JSF to the same SFSB instance constitutes a single thread or two threads?

Every http request is handled by a new thread. So as long as the requests overlap then you will get two threads calling the bean. However seam will stop this happening by serializing access to the conversation. 

I always thought that there was a 1:1 ratio b/n HTTP request and a thread in the server/JVM.  Is this correct?

Yes

In the Eclipse debugger I am not seeing an extra thread being spawned...

And what if the use case actually requires two simultaneous method calls to the same SFSB?  Then what?  You change the scope of the comopnent from conversation to session?

When I tried that there was an exception requiring @Synchronized for my SFSB.

This is disallowed by the EJB spec. If you need two threads to access the data at once then you need to used a session scoped POJO and provide your own thread safety.

[gonorrhea]

You are most likely referring to this in JSR-220 CORE:

4.7.11 Non-reentrant Instances
The container must ensure that only one thread can be executing an instance at any time. If a client
request arrives for an instance while the instance is executing another request, the container may throw
the javax.ejb.ConcurrentAccessException to the second client. If the EJB 2.1 client
view is used, the container may throw the java.rmi.RemoteException to the second request if
the client is a remote client, or the javax.ejb.EJBException if the client is a local client.



Note that a session object is intended to support only a single client. Therefore, it would be an
application error if two clients attempted to invoke the same session object.
One implication of this rule is that an application cannot make loopback calls to a session bean instance.

Ok, so I'm not referring to this situation.  In my code, I have one client (one JSF) that is calling two business methods in a SFSB simultaneously (one via an action handler in a4j:commandButton and the other is an action handler in a4j:jsFunction that is fired onsubmit of button).  Same client, same LRC.  This should be legal as per JSR220.

Anyways, I don't get a runtime exception when this code execs, so I guess it's ok.

I'm just trying to find a workaround for the terrible back button calls destroy() method disaster with a4j:commandButton. Nobody has been able to point out why the destroy() method is getting called (or more precisely, why is the LRC - that hasn't timed out or been demoted - being discarded which is causing the @Remove destroy() method to get called?)

And my workaround is described above but I need to synchronize the time both methods take to execute so the modalPanel displays for the entire req/resp cycle.