1 of 1 people found this helpful
using that "ancient" version - there are next scenarios:
- Without using queue requests will be just sent concurrently. So you should care about concurrency support at server side level objects.
- Using queue(till the version where we redesigned queue and introduced a4j:queue component) things will become even worse. One request will replace any other if them defined with the same queue. So speaking kindly in that version it was not real "queue", it supported only all the events grouping and sending one of them. So if requests from different regions/forms getting grouped - updates from the first ones will not occur as the only latest from anther region getting sent.
And for sure there could be some additional issues which need to be checked in jira as it not possible to remember possible ones for so long time
Thanks for shedding some light on this. The behavior you described for using a queue is exactly the behavior we saw -- the second request would overwrite the first. However, is that behavior possible even if we aren't using a queue explicitly?
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral
+1 203-404-4848 x3
See you at JAX and JSF Summit 2010 June 20-23rd in San Jose: http://jaxconf.com/
Any thoughts on the last message?
No if you not using queue - both requests should be fired.. and the problem in your case seems how them processed (the second for example could be finished faster thanthe first)..
Maybe it's better to workaround that by disabling the form controls in such cases when concurrency should be avoided?