Conversation Concurrent access problem

[ahmadadly]

Hi everyone, I faced from few days ago a problem that is may be known for people who used Seam from long time ago. I have a seam project that contains a screen, which can be used as an entry screen for Cashiers to insert orders and products in our system. I am using Seam 2.1.1.GA

This entry screen contains a lot of AJAX controls, that get an inputs from the cashier, like product bar-code and refresh another controls that describing the product name, available product quantities in the stock, product price and any taxes on this product.

Also the entry screen contains a payment type, a quantity of products field which cause to reRender the Total field that calculated from multiplying quantity & product-price.

To not be boring, this screen contains a lot of AJAX requests and reRendering.

The problem now is that I got a Concurrent conversation call with concurrent timeout exception when dealing with that screen.

After many searching and reviewing the Seam tutorial, I realized that the problem is because Seam conversation components doesn't support concurrent access at the same time. (Conversational components don't allow real concurrent access).

What a mess, This screen is serving the Order entity in database, therefor, it has a OrderHome class as a Seam component that serves the screen.

As you know from my discussion, I tried to use the solutions mentioned in tutorial at How should we design our conversational AJAX application? without any success that leads me to suspect that may I have designed my screen in the best design.

So can anyone help me to provide a link or article or even a sample project that contains the same scenario or solve the problem I have with concurrent access a conversation components?

Thanks in advance.

[asookazian]

http://www.jboss.org/community/wiki/DesignofRichFacesa4jqueue

5.5.3. Queue Principles

Starting from 3.3.0 version RichFaces has an improved queue.

There are some reasons why the queue has been improved. In previous versions the queue had quite simple implementation: it sent to the server only the last Ajax request out of all requests coming in the queue during request delay.

The improved queue allows to

    *

      Eliminate the possibility of collisions when several JSF requests pass the JSF lifecycle at the same time. The queue prevents sending such requests. Only one request is processed. The rest ones are waiting.
    *

      Reduce the traffic between browser and the server. The "similar" requests came within request delay are absorbed. Only the last one is actually sent. Reducing the number of request reduces the server load. 

There are 4 types of the queue:

    *

      Global default queue, defined in the web.xml file
    *

      View scoped default queue
    *

      View scoped named queue
    *

      Form-based default queue

http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/docs/devguide/en/html/ArchitectureOverview.html

I actually use the following config in my current app and there have been no negative consequences that we've detected:

Global default queue has application scope and is defined in the web.xml

It can be done as follows:


...

<context-param>

   <param-name>org.richfaces.queue.global.enabled</param-name>

   <param-value>true</param-value>

</context-param>

...

The global default queue is disabled by default, because artificial serializing of all Ajax requests on a page can significantly affect expected behavior. 

JBalunas created a JIRA to have a better explanation of that last statement, I wasn't quite sure exactly what that means....

[ahmadadly]

Hi again,
Thanks Arbi for you reply, I think your solution is the nearest applicable solution for this problem. I have applied it beside using <a4j:jsFunction> to reduce the Form submission and Response size.

Both of them (reduce response size by eliminating the undesired reRender controls, and using queue) solves this Excpetion.

I hope this topic helps others to find the solution. :)

Best Regards

[nepoez.nepoez.gmail.com]

event queue works perfectly for me.  Unfortunately Seam's remoting doesn't have this concept!  There are certain things I want to use remoting instead of A4J because it's faster, but at the risk of concerrency problem with conversations