ZK Developer's Guide/ZK in Depth/Event listening and processing/Thread Model

This documentation is for an older version of ZK. For the latest one, please click here.

For each desktop, events are processed sequentially, so thread model is simple. Like developing desktop applications, you don't need to worry about racing and multi-threading. All you need to do is to register an event listener and process the event when invoked.

Tip: Each event listener executes in an independent thread called event processing thread, while the ZUML page is evaluated in the servlet thread.

Tip: The use of the event processing thread can be disabled such that all events are processed in the Servlet threads. It has a little bit better performance and less integration issues. However, you can not suspend the execution. Refer to the Use the Servlet Thread to Process Events section in the Advanced Features chapter.

Suspend and Resume

For advanced applications, you might have to suspend an execution until some condition is satisfied. The wait, notify and notifyAll methods of the Executions class are designed for such purpose.

When an event listener want to suspend itself, it could invoke wait. Another thread could then wake it up by use of notify or notifyAll, if the application-specific condition is satisfied. The modal dialog is an typical example of using this mechanism.

 public void doModal() throws InterruptedException {
 ...
     Executions.wait(_mutex); //suspend this thread, an event processing thread
 }
 public void endModal() {
 ...
     Executions.notify(_mutex); //resume the suspended event processing thread
 }

Their use is similar to the wait, notify and notifyAll methods of the java.lang.Object class. However, you cannot use the methods of java.lang.Object for suspending and resuming event listeners. Otherwise, all event processing will be stalled for the associated desktop.

Notice that, unlike Java Object's wait and notify, whether to use the synchronized block to enclose Executions' wait and notify is optional. In the above case, we don't have to, because no racing condition is possible. However, if there is an racing condition, you can use the synchronized block as what you do with Java Object's wait and notify.

 //Thread 1
 public void request() {
     ...
     synchronized (mutex) {
         ...//start another thread
         Executions.wait(mutex); //wait for its completion
     }
 }

 //Thread 2
 public void process() {
     ... //process it asynchronously
     synchronized (mutex) {
         Executions.notify(mutex);
     }
 }