----- Original Message ----- 
From: "Bob Lee" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 28, 2003 10:00 AM
Subject: Re: Session-scoped forms and synchronization...


> Craig R. McClanahan wrote:
>
> > Well, you can get more than one *created*, but only one will actually
> > be stored as a session attribute if the attribute name is the same.
> > Synchronizing the session.setAttribute() method would be pointless;
> > the container guarantees that this won't break anything.  So, exactly
> > what portion of the code would you propose to synchronize?
>
> One will overwrite the other in the session, yes, but the
> RequestProcessor doesn't pull it back out of the session. It uses the
> instance it created, so both could be used concurrently.

The problem you are describing here is a real one. But synchronizing
a portion of RequestProcessor would not *cleanly* solve the problem:

1) Two concurrent threads could still corrupt the same session scoped
    form bean after the threads leave the synchronized section.

2) The problem is due to concurrent threads from ONE user and
    synchronizing a portion of RequestProcessor might have
    impact to ALL users' threads. (You do not want to wait because
    someone else is creating his/her form bean).

We just have this considered but our codes have not been
released with Carrier yet. The idea is to use a filter to synchronize
on a *personal* session scoped object. So nothing need to
be changed in the RequestProcessor.

But it requires Servlet 2.3 in place and could be *very* application 
specific due to our requirements. For example, we do not allow
the second thread to enter the RequestProcessor if the first one
has not been finished yet (very conservative except for cancel event).
We also have to deal with cases when the first thread is a long
running job.

I would suggest people consider filters when solving this problem 
in proposals. Filters can be used as options to protect system's
integrity.

Any other alternatives or ideas?

>
> Bob
>
>

Jing
Netspread Carrier
http://www.netspread.com


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

Reply via email to