Can a single mutable container be safely shared across multiple application instances / sessions?
I have a lookup table which users can add new items into. The lookup table contains the list of items displayed in a Select / drop down box.
What I’d like to do is have the drop down auto-update when users (say from another browser session) add new items to the lookup table.
So I’m thinking if I bind the lookup table to a globally shared container, then back each app instance’s drop down box with this container, then they have a shared data source that can notify them when new items appear.
But would it work? Is it safe to share a container across multiple application instances / browser sessions?
Typically it is not a good idea to share containers because they are stateful as sorting and filtering takes place in the container and affects what itemIds and items are returned to the component. In practice this means user sessions will interfere with each other and the results are not what you would expect.
If you make your own container implementation you are of course free to make it such that it can safely be shared but the containers in the Vaadin core cannot be. Typically you are better of storing the data in a shared way (database, static, etc.) and create one container per component instance.
Does this mean in cases where I use all the items in the container as is, without sorting / filtering, then there’s no problem? (I’m thinking of a basic BeanItemContainer here)
Yes, this is the other option I’m thinking about. When would you refresh the container in this case, since there is no update notification anymore?
My overall layout is a master-detail view. The master is a table with maybe 100+ items, and the detail is a form bound to the item selected in the table. The lookup table is used in the drop-down list on one of the form’s fields, and the lookup may contain 20+ items.
If I go with the 2nd method (1 container per component instance), then I could refresh the form’s drop-down list by clearing and re-populating the container each time an item is selected in the master table. However, this causes a lot of redundant operations when the lookup table hasn’t changed, especially if many concurrent users sift through all the items in the master table (and go up and down etc).
Or perhaps the redundancy is something I just have to put up with?