Hi,
OK. What about several such arraylists/html:options ? We have around 10
drop-downs that are populated. Can't the reload intervene between arraylists
rather than midway through a single arraylist ? It seems that it can ?
Thanks,
Mohan
It depends on the precise implementation of the Iterator that ends up
getting created, but I would bet that you won't have a problem, if you do
this carefully. Here's a walkthrough of a typical scenario:
1) User 1 requests a page that includes an <html:options> tag
based on a ArrayList under servlet context attribute "foo".
2) Inside the implementation of OptionsTag, an Iterator over the
ArrayList at variable "foo", and starts rendering the options.
3) User 2 requests the administrative function to refresh the list.
4) The Action responding to user 2's request builds a new ArrayList
in a local variable (not yet added to the servlet context).
5) User 1's tag is still iterating over the old list, with no problems.
6) User 2's request has completed the new ArrayList, and only now
stores it under the servlet context attribute "foo" key (replacing
the original list.
7) The Iterator that is being used by User 1 is still operating on the
old list (so the new changes are not visible on this request), but
it does NOT see any corrupted data.
As long as the action in step (6) is atomic (in other words, you don't try
to replace the servlet context attribute until your new list has been
completely created), you should never have a problem -- a particular user
request that is running the <html:optoins> tag will see EITHER the old
list OR the new one, but will never see any corrupted combination, or half
completed new list.
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
