-
FEATURED COMPONENTS
First time here? Check out the FAQ!
I am building a small framework on top of zk for my company and have a few questions regarding the zk thread model.
The developers guide says the zk thread model is simple, implying one shouldn't worry about concurrency. It is nice to know and makes very much sense to me since even though zk spawns a new thread for every event listener these listeners get treated one after another. So no concurrency. But what about sharing objects between threads? Say I have a global context for my application with all sensitive data on it and want to use it everywhere else in the application. I guess it still is dangerous to use that object as it is, not worrying about different threads accessing it? I had a situation where an event listener thread executed correctly the code of that shared "context" object, but the modifications he made on his thread working area weren't saved back into the memory shared by all threads. Shouldn't the developers guide mention that risk? What are your comments and recommendations on that issue?
Concerning the modal windows. The guide says it can only be "run" in an event listener since it has to pause the thread. I managed to make a popup in the doAfterCompose of my main window's composer. Does this mean that the composer of the main object is executed in an event listener thread (or at least not in the servlet thread)?
What about the servlet thread? Could you please give some input about how zk handles it (to better understand security issues and the zk LocalThread mechanism)?
Regards
@Yvan
There're some tips for your questions:
1. Use Server Push to solve multi-threads problem. Please read our small talk "Integrate Server Push with ListModel".
2. If you stop a thread who represents a composer, it's usual an event listener thread.
3. Some small talks were talking about our composer (a servlet in MVC model), you could read "An Introduction of ZK Composer" or other small talks.
/Joy
Thank you very much joylo,
But.
1. Please correct if I am wrong but the Server Push has more to do with outOfDesktop events that happen behind closed doors and that once done get "published" by sending events to the Desktop. If so, I don't think that can help me create a thread safe context object (one-desktop-wide)
2. So the zk loader (http://www.zkoss.org/javadoc/3.6/zk/org/zkoss/zk/ui/util/Composer.html) creates the main component (index.zul) in the servlet thread, but then starts a new event processing to treat the doAfterCompose event as any other event? Not that it really matters, but is nice to know.
3. I already read about the composer :)
My question I guess is actually: is there a known risk that shared objects may get inconsistent if used without precaution in an application that accesses them from different *sequentially working, ok* threads? If yes, which is the case since I already got these situations, how do you recommend to prevent it? Is there any known technique such as for example the LocalThread variable that gets correctly initialized for each newly spawn event but that unfortunately doesn't meet my requirements since is per definition local to a thread and what I need is a global variable.
Thx
Hy Yvan,
what shared objects you mean ? Or what would you be share ?
Say you have a MyContext ctx instance on which you store some data every once in while.
I need guarantees that if I say ctx.setValue(value) from anywhere in the code in different event process threads such as onClick() or onSelect(), then I get exactly the right value elsewhere where I say ctx.getValue(). This is not the case by default with threads (!) Every thread keeps its own local heap with all the variables and unless your code is thread safe, you can't be sure of anything. This is the reason LocalThread variables exist in the first place.
Maybe the desktop could solve this issue?
@Yvan
It should see what scope will you need to store data. If just use the data in different "event threads", maybe you could save the ctx instance in request scope.
If there're different users (different servlet threads) need to get data from ctx, saving in session scope is better.
Actually we won't use threadlocal to store anything which another thread will use. ZK scope is like a conception of space, but Web Application scope seems like
a conception of time. It's much better to use Web Application scope in this case.
/Joy
Thanks again joylo for trying to help.
I have no problem storing the context since it's good enough to have a reference on any of the scopes you cite;
My problem is how to make sure the object I store is thread-safe. I could use any of the standard approaches (http://en.wikipedia.org/wiki/Thread_safety) such as writing re-entrant code or just synchronizing the methods but I want to know whether something generic was implemented in the framework to ease my pain :)
Does someone see what my problem actually is? :-)
PS. Am I the only one worrying about these thread issues here, or maybe I really do miss a piece of zk-education big time :)
@Yvan
Hmmm... Maybe I was misunderstood this question :-(
But what the data storing i said, it could also solve a part of the thread-safe problem.
If you're using WebApp scope (like SessionScope) to store the object, using the ZK Composer (every user should have their own composer) as a controller,
there will no thread-safe issue happened by using ZK. If stored objects in ZK scope, you may use "synchronize" or any other method to make sure that only
the same user can access the object.
For example, you could use a Queue to save a key for user id (If you have login validate) and a value with the object you want, then only who has the same
user id can access the target object. Thread-safe problems shouldn't be handle by ZK or any other frameworks.
Wish these tips will helps you... :)
Asked: 2009-08-17 10:07:38 +0800
Seen: 883 times
Last updated: Aug 20 '09