Event Threads"
| Line 3: | Line 3: | ||
{{DeprecatedSince| 7.0.0}} | {{DeprecatedSince| 7.0.0}} | ||
{{notice| text=according to Java Servlet Specification that may prohibit the creation of new threads}} | {{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 | + | 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 | + | 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]]). (For ZK 1.x, 2.x and 3.x, the event processing thread is enabled by default.) |
<source lang="xml" > | <source lang="xml" > | ||
| Line 49: | Line 49: | ||
{{ZKDevelopersReferenceHeadingToc}} | {{ZKDevelopersReferenceHeadingToc}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
{{ZKDevelopersReferencePageFooter}} | {{ZKDevelopersReferencePageFooter}} | ||
Revision as of 04:23, 28 April 2022
Deprecated Since 7.0.0
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). (For ZK 1.x, 2.x and 3.x, the event processing thread is enabled 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), depends on Messagebox and modal windows a lot, and does not have a lot of concurrent users.
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.
| 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.
Threre are several implementations to solve the integration issue, such as HibernateSessionContextListener (they can be found under the org.zkoss.zkplus package). |
| 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. |