Hi, Lam,

I assume you are asking me what I was talking about. (When addressing something said, it is a good idea to leave that somewhere in your reply.) Anyhow, if you are asking about what I said, here is a bit.

Usually there are a given number of options discussed for maintaining state with a user. You are familiar with them and the issues, I assume, from cookies, hidden parameters, session storage, database storage, etc. I have found for my uses that an application level manager for data is better than any of the standard solutions for most of my situations. You have to build the manager to do what you want, which usually will have to be multithreaded. Some of my manager parts use things like Doug Lea's worker threads and are triggered by events, such as incoming requests. Some of my manager uses the Java Timer with subclasses of TimerTask, which are also multithreaded and are triggered my timed monitoring processes. The variety and details is up to you. That is what I like to do, in any event, rather than just rely on session management as coded by the server component, etc.

Michael McGrady.

Koon Yue Lam wrote:

thanks to Frank !
and Michael:
what u mean an application level multi-threaded program? is it a
background deamon / process to store data that likely to be store by
session ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to