0

ZK Thread model. Servlet thread

asked 2009-08-17 10:07:38 +0800

Yvan gravatar image Yvan
18

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

delete flag offensive retag edit

7 Replies

Sort by ยป oldest newest

answered 2009-08-18 00:53:13 +0800

joylo0122 gravatar image joylo0122
688 1
www.zkoss.org

@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

link publish delete flag offensive edit

answered 2009-08-18 12:08:50 +0800

Yvan gravatar image Yvan
18

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

link publish delete flag offensive edit

answered 2009-08-18 13:38:30 +0800

terrytornado gravatar image terrytornado flag of Germany
9393 3 7 16
http://www.oxitec.de/

Hy Yvan,

what shared objects you mean ? Or what would you be share ?

link publish delete flag offensive edit

answered 2009-08-18 14:09:22 +0800

Yvan gravatar image Yvan
18

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?

link publish delete flag offensive edit

answered 2009-08-19 01:34:13 +0800

joylo0122 gravatar image joylo0122
688 1
www.zkoss.org

@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

link publish delete flag offensive edit

answered 2009-08-19 10:06:49 +0800

Yvan gravatar image Yvan
18

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 :)

link publish delete flag offensive edit

answered 2009-08-20 01:25:34 +0800

joylo0122 gravatar image joylo0122
688 1
www.zkoss.org

updated 2009-08-20 01:26:48 +0800

@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... :)

link publish delete flag offensive edit
Your reply
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools

Follow

RSS

Stats

Asked: 2009-08-17 10:07:38 +0800

Seen: 883 times

Last updated: Aug 20 '09

Support Options
  • Email Support
  • Training
  • Consulting
  • Outsourcing
Learn More