One Container to Many Tables?

To save memory on the server-side, I want to use a single set of data to back multiple Table instances for a user.

In my Vaadin 7.0.4 app, the user can have multiple UI instances open in browser windows/tabs. Each UI has several Vaadin tabs (TabSheet tabs). All of these multiple tabs in multiple windows all display a Table containing the very same data. The data is read-only – the only usage is for the user to select a row. That selected row’s ID is used by other widgets in the Layout.

Rather than multiple that set of data backing the Table’s BeanItems, can I create one BeanItemContainer to back all those Table instances? Or does each Table need its own solitary backing Container?

If using one BeanItemContainer for many Table instances is not the way to go, could I assign the same set of BeanItems to many BeanItemContainers?

–Basil Bourque

That should be fine for read-only tables. You’ll have to be aware of the possibility of stale cache. When one table gets updated then all the other tables linked to the same data, in my case MySQL, will have out dated information and you’ll have to manually refresh them all.

Dana

The potential problem with this is the possibility of memory leaks through Tables etc. listening to the same container. Thus, this can “bind” the lifecycles of all those tables and containers and views with the tables. If that is not a problem in your application (e.g. lifecycles of those components related anyway, no sharing between sessions/users), this should work just fine - especially for read-only scenarios, but also read-write if all modifications are performed using Vaadin data model APIs.

Bean(Item)Container does not support getting the BeanItem instances from elsewhere, but it should not be too hard to create a subclass of AbstractInMemoryContainer that would support sharing BeanItems if you want to reduce the memory overhead of extra items and properties without sharing the whole containers. It might even be possible to do this with a very small customized subclass of AbstractBeanContainer. That does not fundamentally resolve the memory leak issue mentioned above, though - just reduce the overhead and the scope and likelihood of potential leaks somewhat.