We had a discussion today and the following “thought experiment” came up. The question is: there a fundamental race condition between the client and server in Vaadin… what does Vaadin do when it occurs?
For example, suppose in a Vaadin application there is a button. On the server, there is some server-side thread that is unrelated to Vaadin that at any time may decide to remove the button from the GUI.
Of course the server-side thread must properly lock the Application instance (or VaadinSession in 7.x) before doing so, but otherwise this is perfectly normal. Then, the button will disappear from the GUI after the next time the client contacts the server for whatever reason (perhaps due to Refresher). So far so good.
Now suppose that just after the server removes the button on the server, someone presses the button on the client GUI. When the client contacts the server, the thread handling that HTTP request will discover that the button no longer exists in the Application… it will encounter an unknown widget ID or whatever.
What happens next? Does this cause a “session out of sync” red banner? Is the button click ignored? Etc.
The button click is just one example. There are lots of other variants of this problem. What is Vaadin’s strategy for handling this race condition?
I’m curious about the behavior in both 6.x and 7.x (if they behave differently).
On Vaadin 6, there is a log entry on the server about variable changes for a component that does not exist but if I remember correctly this might also cause an out of sync situation in addition to that.
On Vaadin 7 (again if I remember correctly), if the component has been removed before the event is received, there is a log entry (see AbstractCommunicationManager.handleBurst() etc.) but the RPC call or variable change is ignored and the application does not “crash” from the user’s point of view.
The removal of a component is the primary issue from the point of view of the framework, handling other race conditions is up to component implementations.
With how most of the standard components are designed, in many cases such extra events should not cause problems and either the server state of the component “wins” on the next update or the update from the client is performed late.