You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Bob Lee <cr...@crazybob.org> on 2003/10/27 20:22:23 UTC
Session-scoped forms and synchronization...
Does Struts synchronize on session-scoped forms? For example, can I
assume that Stuts won't modify the fields on a session-scoped form in
response to one request while an action is still using it?
Someone on the user list says that it does not.
Thanks,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Session-scoped forms and synchronization...
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Bob Lee" <cr...@crazybob.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Session-scoped forms and synchronization...
Posted by Bob Lee <cr...@crazybob.org>.
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.
> Feel free to submit a patch, but I'm betting the performance cost of
> implementing it will be horrendous. If you're concerned about
> multiple simultaneous requests, you should really be using request
> scope form beans anyway.
The performance cost will be nothing. All this will do is prevent
concurrent requests within the scope of an action form instance. I'm
worried about unexpected browser behavior leading to incosistent state
and weird synchronization errors; probably not a problem with posts, but
definitely an issue with gets. I can't think of a valid use case where
two request should be able to modify the same session-scoped action form
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Session-scoped forms and synchronization...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Bob Lee wrote:
> I looked at the latest source and it doesn't appear to synchronize.
> Though you could fix this using a custom RequestProcessor, I think it
> qualifies as a bug.
>
> First, it should synchronize form creation. Right now more than one
> instance of a session-scoped form can be created.
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?
>
> Second, it should synchronize access access to session scoped forms.
> Right now, an action can be working on a session-scoped form while the
> RequestProcessor is populating the same form with properties from a
> concurrent request.
>
> If you guys agree, I will fix the default RequestProcessor and submit
> a patch.
>
Feel free to submit a patch, but I'm betting the performance cost of
implementing it will be horrendous. If you're concerned about multiple
simultaneous requests, you should really be using request scope form
beans anyway.
> Thanks,
> Bob
>
Craig
> Bob Lee wrote:
>
>> Does Struts synchronize on session-scoped forms? For example, can I
>> assume that Stuts won't modify the fields on a session-scoped form in
>> response to one request while an action is still using it?
>>
>> Someone on the user list says that it does not.
>>
>> Thanks,
>> Bob
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Session-scoped forms and synchronization...
Posted by Bob Lee <cr...@crazybob.org>.
I looked at the latest source and it doesn't appear to synchronize.
Though you could fix this using a custom RequestProcessor, I think it
qualifies as a bug.
First, it should synchronize form creation. Right now more than one
instance of a session-scoped form can be created.
Second, it should synchronize access access to session scoped forms.
Right now, an action can be working on a session-scoped form while the
RequestProcessor is populating the same form with properties from a
concurrent request.
If you guys agree, I will fix the default RequestProcessor and submit a
patch.
Thanks,
Bob
Bob Lee wrote:
> Does Struts synchronize on session-scoped forms? For example, can I
> assume that Stuts won't modify the fields on a session-scoped form in
> response to one request while an action is still using it?
>
> Someone on the user list says that it does not.
>
> Thanks,
> Bob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org