Before websockets, web UIs had been some kind of single threaded. Which should mean, that only the “request thread” changed the state of the ui from a session.
But now it is possible, that differnt threads do their changes at the same time on the same ui instance. Since the most UI kits like swing and swt are single threaded, i think that a multi threaded approach would also cause troubles using vaadin.
What do you think about that issue? Is a single threaded UI environment planned by vaadin 7?
Vaadin synchronizes all user initiated threads that access UI around the application instance. Each other threads that access Vaadin UI
should/must do the same. If they don’t it is just a matter of time when concurrency issues will arise. The rule is the same for all non browser(read user) invoked threads with or without any “push solution”.
As concurrency is one of the most difficult areas in development, I agree we could add some helpers to simplify this. E.g. we could have invokeLater(Runnable) method in Application to mimic similar method in SwingUtils. I haven’t thought of them before by myself, I have just relied on synchronized(compoment.getApplication()) {doStuffWithThings();} style code snippets. Below is a code example how from the demo app (which appeared to have a bug just some minutes ago). The array “windows” contains all window instances (from n users):
for (int i = 0; i < windows.length; i++) {
TestWindow w = windows[i]
;
synchronized (w.getApplication()) {
w.addMessage(msg);
}
}
If you have some more fine grained ideas, please let us know.
thanks a lot. For concurrency issues that approach seems to work properly.
But another issue would be to handle session scoped contexts. Since the ThreadLocalPattern is heavily used in web environments, every time an ui instance is processed by a thread, the session scoped context has to be applied to the thread.
Before webSockets, the startTransaction and endTransaction method of the applicationContext could be used. The context was applied on startTransaction and removed on endTransaction. So it was ensured, that the session scoped contexts are available all the time.
Using websockets and threads does not necessarily invoke the methods of applicationContext. So the developer has to ensure, that the scoped contexts are applied to their thread local fields.
Is there any kind of support planned for vaadin 7?
Something like
application.syncExec(Runnable runnable);
I am going to submitt a contribution for the dontpush ozone addon that handles this issue.
new UnitOfWork(application, window) {
@Override
protected void run() {
// do some ui state changing operation
myLabel.setValue()
}
}.executeSafe();
It invokes all transaction listeners before calling the run-method. So thread locals will be available in the run-method nevertheless which thread invoked the UnitOfWork.