Event Threads"

From Documentation
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
{{ZKDevelopersGuidePageHeader}}
+
{{ZKDevelopersReferencePageHeader}}
  
−
__TOC__
+
{{DeprecatedSince| 7.0.0}}
 +
{{notice| text=according to Java Servlet Specification that may prohibit the creation of new threads}}
 +
By default, ZK processes an event in the same Servlet thread that receives the HTTP request. It is the suggested approach because the performance is better, and it is easy to integrate with other frameworks. (Many frameworks store per-request information in the thread-local storage, so we have to copy them from a servlet thread to the Event Processing Thread).
  
−
By default, ZK processes an event in the same Servlet thread that receives the HTTP request. It is the suggested approach because it is efficient and easy to integrate with other frameworks<ref>Many frameworks store per-request information in the thread-local storage.</ref>.
+
However, it also implies the developer cannot suspend the execution. Otherwise, the end-users won't see any updates from the server. To solve it, ZK provides an alternative approach: processes the event in an independent thread called the event processing thread. Therefore, the developer can suspend and resume the execution at any time, without blocking the Servlet thread from sending back the responses to the browser. To turn it on, you have to specify the following in <code>WEB-INF/zk.xml</code> ([[ZK_Configuration_Reference/zk.xml/The_system-config_Element/The_disable-event-thread_Element |ZK Configuration Guide: disable-event-thread]] , after ZK 5, the event processing thread is disabled by default.)
−
 
 
−
However, it also implies the developer cannot suspend the execution. Otherwise, the end user won't see any update from the server. To solve it, ZK provides an alternative approach: processes the event in an independent thread called the event processing thread. Therefore, the developer can suspend and resume the execution at any time, without blocking the Servlet thread from sending back the responses to the browser. To turn it on<ref> For ZK 1.x, 2.x and 3.x, the event processing thread is enabled by default.</ref>, you have to specify the following in <tt>WEB-INF/zk.xml</tt>.
 
  
 
<source lang="xml" >
 
<source lang="xml" >
Line 13: Line 13:
 
</source>
 
</source>
  
−
Here is the advantages and limitations about using the Servlet thread to process events. In the following sections we will talk more about the limitations and workarounds when using the Servlet thread.
+
In short, it is recommended to disable the event thread. Enable the event thread only if the project does not need to integrate other frameworks (such as Spring), depending on <javadoc>org.zkoss.zul.Messagebox</javadoc> and modal windows a lot, and do not have a lot of concurrent users.
  
 +
Here are the advantages and limitations of using the Servlet thread to process events. In the following sections, we will talk more about the limitations and workarounds when using the Servlet thread.
  
−
{| border="1px"
+
{| class='wikitable' | width="100%"
 
!  
 
!  
 
! <center>Using Servlet Thread</center>
 
! <center>Using Servlet Thread</center>
Line 25: Line 26:
 
| Less integration issues.
 
| Less integration issues.
  
−
Many containers assume the HTTP request is handled in the servlet thread.
+
Many containers assume the HTTP request is handled in the Servlet thread, and many frameworks store per-request information in the thread-local storage.
−
| You may have to implement <tt>EventThreadInit</tt> and/or <tt>EventThreadCleanup</tt> to solve the integration issue.
 
  
−
ZK and the community keep providing versatile implementations to solve the integration issue.
+
| You may have to implement <code>EventThreadInit</code> and/or <code>EventThreadCleanup</code> to solve the integration issue, such as copying the per-request information from the Servlet thread to the event processing thread.
 +
 
 +
DEPRECATED SINCE ZK 6.0.2
 +
There are several implementations to solve the integration issue, such as [https://www.zkoss.org/javadoc/9.6.5/zk/org/zkoss/zkplus/hibernate/HibernateSessionContextListener.html HibernateSessionContextListener] (they can be found under [http://www.zkoss.org/javadoc/9.6.5/zk/org/zkoss/zkplus/package-summary.html the org.zkoss.zkplus package], up to ZK 9.6. This Class was removed in ZK 10 and later).
  
 
|-
 
|-
Line 37: Line 40:
 
| No limitation at all.
 
| No limitation at all.
  
−
|}
+
|-
 +
| Performance
 +
| No extra cost
  
−
<blockquote>
+
| It executes a bit slower to switch from one thread to another, and it might consume a lot more memory if there are a lot of suspended event processing threads.
−
----
 
−
<references/>
 
−
</blockquote>
 
  
−
=== Modal Windows ===
+
|}
−
You can not use the modal window anymore. You can create the same visual effect with the highlighted mode. However, at the server side, it works just like the overlapped mode – it returns immediately without waiting for user's response.
 
−
 
 
−
<source lang="java" >
 
−
win.doHighlighted(); //returns once the mode is changed; not suspended
 
−
</source>
 
−
 
−
=== Message Boxes ===
 
−
The message boxes returns immediately so it always returns <tt>Messagebox.OK</tt>. Thus, it is meaningless to show buttons other than the OK button. For example, the <tt>if</tt> clause in the following example is never true.
 
−
 
 
−
<source lang="java" >
 
−
if (Messagebox.show("Delete?", "Prompt", Messagebox.YES|Messagebox.NO,
 
−
    Messagebox.QUESTION) == Messagebox.YES) {
 
−
    this_never_executes();
 
−
}
 
−
</source>
 
−
 
−
Rather, you have to provide an event listener as follows.
 
−
 
 
−
<source lang="java" >
 
−
Messagebox.show("Delete?", "Prompt", Messagebox.YES|Messagebox.NO,
 
−
    Messagebox.QUESTION,
 
−
    new EventListener() {
 
−
        public void onEvent(Event evt) {
 
−
            switch (((Integer)evt.getData()).intValue()) {
 
−
            case Messagebox.YES: doYes(); break; //the Yes button is pressed
 
−
            case Messagebox.NO: doNo(); break; //the No button is pressed
 
−
            }
 
−
        }
 
−
    }
 
−
);
 
−
</source>
 
−
 
−
The event listener you provided is invoked when the user clicks one of the buttons. Then, you can identify which button is clicked by examining the data (Event's <tt>getData</tt>). The data is an integer whose value is the button's identifier, such as <tt>Messagebox.YES</tt>.
 
−
 
 
−
Alternatively, you can examine the event name:
 
−
 
 
−
<source lang="java" >
 
−
public void onEvent(Event evt) {
 
−
    if ("onYes".equals(evt.getName())) {
 
−
        doYes(); //the Yes button is pressed
 
−
    } else if ("onNo".equals(evt.getName())) {
 
−
        doNo(); //the No button is pressed
 
−
    }
 
−
}
 
−
</source>
 
−
 
−
'''Note''': The event name for the OK button is <tt>onOK</tt>, not <tt>onOk</tt>.
 
−
 
 
−
=== File Upload ===
 
−
The file upload dialog is no longer applicable. Rather, you shall use <javadoc>org.zkoss.zul.Button</javadoc> or <javadoc>org.zkoss.zul.Toolbarbutton</javadoc> with upload="true" instead. For example,
 
−
 
 
−
<source lang="xml">
 
−
<zk>
 
−
<zscript>
 
−
void upload(Event event) {
 
−
org.zkoss.util.media.Media media = event.getMedia();
 
−
if (media instanceof org.zkoss.image.Image) {
 
−
org.zkoss.zul.Image image = new org.zkoss.zul.Image();
 
−
image.setContent(media);
 
−
image.setParent(pics);
 
−
} else {
 
−
Messagebox.show("Not an image: "+media, "Error", Messagebox.OK, Messagebox.ERROR);
 
−
break; //not to show too many errors
 
−
}
 
−
}
 
−
</zscript>
 
−
<button label="Upload" upload="true" onUpload="upload(event)"/>
 
−
<toolbarbutton label="Upload" upload="true" onUpload="upload(event)"/>
 
−
<vbox id="pics" />
 
−
</zk>
 
−
</source>
 
−
 
 
−
If you prefer to use a dialog (<javadoc method="get()">org.zkoss.zul.Fileupload</javadoc>), please take a look at [[ZK_Component_Reference/Essential_Components/Fileupload | ZK Component Reference: Fileupload]] for more inormation.
 
  
 +
{{ZKDevelopersReferenceHeadingToc}}
  
  
−
{{ ZKDevelopersGuidePageFooter}}
+
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 08:18, 25 July 2024


DocumentationZK Developer's ReferenceUI PatternsEvent Threads
Event Threads


Deprecated Since 7.0.0

Icon info.png Notice: according to Java Servlet Specification that may prohibit the creation of new threads

By default, ZK processes an event in the same Servlet thread that receives the HTTP request. It is the suggested approach because the performance is better, and it is easy to integrate with other frameworks. (Many frameworks store per-request information in the thread-local storage, so we have to copy them from a servlet thread to the Event Processing Thread).

However, it also implies the developer cannot suspend the execution. Otherwise, the end-users won't see any updates from the server. To solve it, ZK provides an alternative approach: processes the event in an independent thread called the event processing thread. Therefore, the developer can suspend and resume the execution at any time, without blocking the Servlet thread from sending back the responses to the browser. To turn it on, you have to specify the following in WEB-INF/zk.xml (ZK Configuration Guide: disable-event-thread , after ZK 5, the event processing thread is disabled by default.) 

<system-config>
    <disable-event-thread>false</disable-event-thread>
</system-config>

In short, it is recommended to disable the event thread. Enable the event thread only if the project does not need to integrate other frameworks (such as Spring), depending on Messagebox and modal windows a lot, and do not have a lot of concurrent users.

Here are the advantages and limitations of using the Servlet thread to process events. In the following sections, we will talk more about the limitations and workarounds when using the Servlet thread.

Using Servlet Thread
Using Event Processing Thread
Integration Less integration issues.

Many containers assume the HTTP request is handled in the Servlet thread, and many frameworks store per-request information in the thread-local storage.

You may have to implement EventThreadInit and/or EventThreadCleanup to solve the integration issue, such as copying the per-request information from the Servlet thread to the event processing thread.

DEPRECATED SINCE ZK 6.0.2 There are several implementations to solve the integration issue, such as HibernateSessionContextListener (they can be found under the org.zkoss.zkplus package, up to ZK 9.6. This Class was removed in ZK 10 and later).

SuspendResume No way to suspend the execution of the event listener.

For example, you cannot create a modal window.

No limitation at all.
Performance No extra cost It executes a bit slower to switch from one thread to another, and it might consume a lot more memory if there are a lot of suspended event processing threads.





Last Update : 2024/07/25

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.


Retrieved from "https://www.zkoss.org/_w/index.php?title=ZK_Developer%27s_Reference/UI_Patterns/Event_Threads&oldid=57291"