Global IndexedContainer, possible?

Hi,

Firstly I just wanted to say what a great framework you guys have here :slight_smile:

I have a general question and I’m not sure if this is best sub forum to ask it. I would like to have a global IndexedContainer for all current user Sessions. Each session would have a table backed by this data, it does not have to specific for any particular Session (no filtering or sorting capabilities). Instead of having potentially hundreds of threads in each session, only one thread would update the IndexedContainer and the changes would be propagated to all users. It seems like a nice solution, however I’m getting a situation where I need to lock each table using “getUI().getSession().getLock().lock()” each time I do an update to avoid the “dirty data” exception. What’s the best way to do this? should I broacast to all sessions to lock the table because a change is coming (is there any guarantee that broadcast would hit first before the changes were made?). Should I have a list of all Session objects, call a lock method before I make the update? Is there an easier way to do this???

Thank you

Hello Bob,

I think you can do this multiple ways, but you have to restructure your Code a bit -

Please follow the following steps -

  • Firstly, Create an application wide singleton
  • This should have 3 APIs, addReference(VaadinSession, Table), removeReference(VaadinSession), updateData(Data).
  • Create a Class level Map to hold values being added by addNewUserReference
  • removeRefence should remove associated value from the map
  • Whenever there is a request for update of data, iterate over the map, get reference to the VaadinSession and update table.
  • In the view where you have a table/combobox override the attach method and detach method.
  • in the attache method, get the reference to singleton class created above invoke addReference api with the current VaadinSession and table component.
  • in the detach method invoke the method removeReference with the current vaadinSession.
  • Once you get notified about the change in data, invoke the updateData method of the Singleton class.

Please let me know if you have any concerns regarding the same.

Thanks,
Krishna.

Hi Krishna,

I’ll look into implementing your suggestions. I am curious however what you think about locking an entire Vaadin Session? My updating thread for the global IndexedContainer runs about once every 2 seconds, before the update occures I lock each Vaadin Session in my application, I then do my update and then release all the locks. I no longer get any exception but I’m wondering if this would have serious unintended consequences on the rest of my application?

Thank you

Hello Bob,

The lock is required for syncronization purpose, and can you explain me further on the design decision why 2 Seconds? Are you developing any mission critical applications? or Trading application? anyway, I don’ t think it would be an issue.

If you are using Vaadin version 7.2.x did you try looking at
PollListener
?

Thanks,
Krishna

Hi Krishna,

To answer your question, its a trading app and why 2 seconds? It seemed like a good update period interval. So if I lock an entire session every 2 seconds I won’t have any major issues, like if the user does something during the update cycle?
I’m not sure PollListener would work since the changes are coming from the server not the client (browser).

Hello Bob,

I wanted you to check if you can push your updates when ever there is a poll request/Event.

As far as I perceive, you would have no issues. basically what I understand from your App is that you have a background thread that is updating the UI continuously.

Also, as a value addon I would suggest you to show last update time somewhere on the UI to let the user know of the last update time. It would be helpful for the user.

Thanks,
Krishna.

While the API would not prevent it in principle, none of the standard container implementations included in Vaadin support sharing the same container between multiple UIs, and especially not between UIs that belong to different sessions.

The fundamental problem (apart from locking, which should be solvable) is listeners: Tables etc. register themselves as listeners for the container, and might not unregister themselves e.g. if the session is terminated or there is some other problem. As the Table has a reference to its parent and indirectly to the UI and the whole session, this means that you might end up with whole sessions remaining as “zombies” in memory even after session termination. This, too, is solvable in non-clustered environments with the use of weak references etc. but the standard containers do not try to address this.