The org.zkoss.zk.ui.event.EventThreadResume interface"
| Line 17: | Line 17: | ||
Notice that <tt>beforeResume</tt> executes in the main thread, so it shares the same thread-local storage with the main thread. On the other hand, <tt>afterResume</tt> executes in the event processing thread, so it shares the same thread-local storage with the event thread (and application event listeners). | Notice that <tt>beforeResume</tt> executes in the main thread, so it shares the same thread-local storage with the main thread. On the other hand, <tt>afterResume</tt> executes in the event processing thread, so it shares the same thread-local storage with the event thread (and application event listeners). | ||
| − | In addition to resuming normally, a suspended event processing thread might be aborted abnormally. For example, when the desktop is | + | In addition to resuming normally, a suspended event processing thread might be aborted abnormally. For example, when the desktop is destroyed, all the suspended event threads will be aborted. When the suspended event processing thread is aborted, an instance is created, and the <tt>abortResume</tt> method is called in the main thread. |
'''Note''': If a suspended event thread is aborted, none of the <tt>beforeResume</tt> and <tt>afterResume</tt> is called. Moreover, the <tt>cleanup</tt> and <tt>complete</tt> methods of <tt>EventThreadCleanup</tt> won't be called, either. Thus, you have to handle all necessary cleanups in <tt>abortResume</tt>. | '''Note''': If a suspended event thread is aborted, none of the <tt>beforeResume</tt> and <tt>afterResume</tt> is called. Moreover, the <tt>cleanup</tt> and <tt>complete</tt> methods of <tt>EventThreadCleanup</tt> won't be called, either. Thus, you have to handle all necessary cleanups in <tt>abortResume</tt>. | ||
Revision as of 01:41, 8 August 2011
Listener:
org.zkoss.zk.ui.event.EventThreadResume
A listener could implement EventThreadResume, such that it will be called after an event processing thread is resumed or aborted.
Notice that it is useless unless the event processing threads are enabled (it is disabled by default).
If a listener implements this interface, an instance is created, and then the beforeResume method is called in the main thread (aka., the servlet thread), when a suspended event thread is being resumed. Then, the afterResume method is called in the event processing thread after the thread is resumed successfully.
If a developer wants to prevent an event from being resumed, he can throw an exception in the beforeResume method.
Notice that beforeResume executes in the main thread, so it shares the same thread-local storage with the main thread. On the other hand, afterResume executes in the event processing thread, so it shares the same thread-local storage with the event thread (and application event listeners).
In addition to resuming normally, a suspended event processing thread might be aborted abnormally. For example, when the desktop is destroyed, all the suspended event threads will be aborted. When the suspended event processing thread is aborted, an instance is created, and the abortResume method is called in the main thread.
Note: If a suspended event thread is aborted, none of the beforeResume and afterResume is called. Moreover, the cleanup and complete methods of EventThreadCleanup won't be called, either. Thus, you have to handle all necessary cleanups in abortResume.
Instantiation: An independent instance of the given class is instantiated each time before the method is invoked. It means it is thread safe, and all information stored in non-static members will be lost after called.