I have several windows in my application, each of which have different push requirements.
Am I supposed to create 1 ICEpush object per application and share it among windows or create one per window?
Since the example code shows doing a lock on ICEPush object while updating from the background thread, does that mean I need to lock on the object even in all my listeners in the main gui code?
How do i dispose off the ICEPush object if the user closes the window, thus ensuring my background threads are killed too?
One per application is enough. When you call “push()” you are telling the Vaadin client code running in the remote browser to pay attention and call the web server for updates.
When you are reacting in a listener that is triggered by a user interaction, you do not need to push. The vaadin UI code in the browser will pick up all the UI changes you are performing as a result of that interaction (i.e. all the listeners, and all events triggered from that listener, until all the code that results from the interaction is done). If you are not pushing, you don’t need to lock.
When the user closes the window, you need to kill your background threads yourself – after all, some of them may legitimately need to keep running. So you need to keep track of your threads as you fork them if you want to interrupt them. Otherwise they will keep running until the end of the session invalidates the references and they get garbage collected.
My question regarding synchronization is not about using push on event handlers on the gui thread.
What it relates to is the fact that due to ICEPush, now there can be multiple threads updating the gui at the same time.
Does that mean all gui updates need to be done within a lock?
Your sample code on the add-ons page shows the background thread using a lock before doing the push.
But does that mean the lock needs to be used in the main gui thread too?
The handling of normal (non-push) requests from the UI is automatically synchronized to the Application instance by the framework.
If using a background thread, you should synchronize all (direct and indirect) UI component state modifications to the same instance.