-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
Joshua Slack wrote:
> -----------------------------
> Please read the FAQ!
> <http://java.apache.org/faq/>
> -----------------------------
>
> This would indeed lock that particular session, but you have to think about
> are you locking it *from*? That session object is unique to a particular
> user, because each user has their own session. It will only be accessed
> from
> multiple threads simultaneously if the same user is making simultaneous
> requests -- possible in a framed environment, but pretty unusual otherwise.
>
> Unfortunately, a small part of our site includes frames. This and redirects
> seem to cause problems for a specific user because he/she is reading or
> writing information to their session simultaneously.
>
> Your explanation on locking an object contained in the session is good. The
> servlet touches a lot of information in the session which is why I was
> thinking I needed to synch the whole session in order to prevent the servlet
> from overwriting the information in a session while another instance was
> reading it. I suppose I need to revisit my implementation?
>
> -- Josh
>
Locking the entire session would be crude but effective, as long as none of the
objects you store in the session are referenced from anywhere else. You will
definitely want to monitor the performance impact of this, however. If any of
these objects are accessible from elsewhere, then locking the session does
*not* block simultaneous access to those objects from their other references --
and you will be back to synchronizing the individual objects in question.
Your comments reminded me of one more common scenario when you can get
simultaneous access, even in a non-framed presentation. Let's say you are
displaying a fairly long page, and the user clicks an already visible hyperlink
(that goes back into your app) without waiting for the entire output to be
presented. It is quite possible that the new request will come in to your
servlets before the previous request has completed generating its output.
(Locking the session would cause this second request to wait for the first one
to complete.)
Craig McClanahan
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]