«

In a JSP/Servlet application, what exactly constitutes a user session?
If I have an application open and I open a new browser window at one
of the pages in the app would this create 2 sessions or still one?
Basically, I was trying to find out if I need to synchronize access to
any session variables in servlet code or that is not necessary.

TIA

wrote:
> In a JSP/Servlet application, what exactly constitutes a user session?
> If I have an application open and I open a new browser window at one
> of the pages in the app would this create 2 sessions or still one?
> Basically, I was trying to find out if I need to synchronize access to
> any session variables in servlet code or that is not necessary.

That is up to the browser.

Let us assume sessions are maintained via cookies not URL
rewriting because cookies are by fat the most common.

When the session is established then the browser get a session
cookie from the server.

All requests coming with that session cookie belongs to that
session.

So it is up to the browser whether it will send the same
cookie for another window or not.

If I remember correct then IE and FF act differently regarding
this.

So be very conservative about what you assume.

Arne

wrote:
> In a JSP/Servlet application, what exactly constitutes a user session?
> If I have an application open and I open a new browser window at one
> of the pages in the app would this create 2 sessions or still one?
> Basically, I was trying to find out if I need to synchronize access to
> any session variables in servlet code or that is not necessary.

This depends on how the browser does things. User sessions are maintained
through either a cookie on the client system whose contents are enclosed with
each HTTP request, or a URL parameter likewise included in each HTTP request.
A second browser instance will not "know" about the cookie or URL parameter,
respectively, and will not send it, thus it will not participate in the first
browser instance's session(s).

--
Lew

Arne Vajhøj wrote:
> That is up to the browser.
>
> Let us assume sessions are maintained via cookies not URL
> rewriting because cookies are by fat the most common.
>
> When the session is established then the browser get a session
> cookie from the server.
>
> All requests coming with that session cookie belongs to that
> session.
>
> So it is up to the browser whether it will send the same
> cookie for another window or not.
>
> If I remember correct then IE and FF act differently regarding
> this.
>
> So be very conservative about what you assume.

You are correct - I just checked with FF and the second instance does indeed
seem to be aware of the first one's session, or perhaps the server is aware of
my IP address and somehow uses that. Regardless, both instances seem to share
the session.

--
Lew

Lew wrote:
> Arne Vajhøj wrote:
>> That is up to the browser.
>>
>> Let us assume sessions are maintained via cookies not URL
>> rewriting because cookies are by fat the most common.
>>
>> When the session is established then the browser get a session
>> cookie from the server.
>>
>> All requests coming with that session cookie belongs to that
>> session.
>>
>> So it is up to the browser whether it will send the same
>> cookie for another window or not.
>>
>> If I remember correct then IE and FF act differently regarding
>> this.
>>
>> So be very conservative about what you assume.
>
> You are correct - I just checked with FF and the second instance
> does
> indeed seem to be aware of the first one's session, or perhaps the
> server is aware of my IP address and somehow uses that. Regardless,
> both instances seem to share the session.

On Windows, at least, multiple Firefox windows are all part of the
same OS process. Multiple IE windows are different processes. This
matches the difference in session behavior.

Mike Schilling wrote:
> On Windows, at least, multiple Firefox windows are all part of the
> same OS process. Multiple IE windows are different processes. This
> matches the difference in session behavior.

Apparently also true on Linux. In fact, when I ssh into a separate Linux box
with XWindows port-forwarded ('-Y' option), if I have FF open on the local
box, then the remote box opens FF in my client process and vice versa.

--
Lew

<> wrote in message
news:304db6b9-f44e-4c55-a915-...
> In a JSP/Servlet application, what exactly constitutes a user session?
> If I have an application open and I open a new browser window at one
> of the pages in the app would this create 2 sessions or still one?
> Basically, I was trying to find out if I need to synchronize access to
> any session variables in servlet code or that is not necessary.
>
> TIA

As an addition to the other comments, it's probably worth adding that the
main reason for synchronizing access to an HttpSession is because there may
be multiple requests (hence multiple threads) in the *same* session...that
is, same browser, same tab etc. After all, a single page may generate more
than one request.

You'll also find that there may be little or no need to synchronize access
to an HttpSession. There's a reasonable expectation that the servlet
container is ensuring that access to its internal attribute map is
thread-safe (although the Tomcat developers had a prolonged argument about
this with 5.x a few years back), and that therefore you'll mainly worry
about synchronization if you need multiple getAtttribute or setAttribute
operations to be atomic.

If you do end up wanting to synchronize, seems to me that synchronizing on
the session is fine. There have been discussions about this, too. Not sure
why, because how many threads will ever be competing for it?

AHS

Arved Sandstrom wrote:
> <> wrote in message
> news:304db6b9-f44e-4c55-a915-...
>> In a JSP/Servlet application, what exactly constitutes a user session?
>> If I have an application open and I open a new browser window at one
>> of the pages in the app would this create 2 sessions or still one?
>> Basically, I was trying to find out if I need to synchronize access to
>> any session variables in servlet code or that is not necessary.
>
> As an addition to the other comments, it's probably worth adding that the
> main reason for synchronizing access to an HttpSession is because there may
> be multiple requests (hence multiple threads) in the *same* session...that
> is, same browser, same tab etc. After all, a single page may generate more
> than one request.

In these AJAX times a single page may flood the server with requests.

> You'll also find that there may be little or no need to synchronize access
> to an HttpSession. There's a reasonable expectation that the servlet
> container is ensuring that access to its internal attribute map is
> thread-safe (although the Tomcat developers had a prolonged argument about
> this with 5.x a few years back), and that therefore you'll mainly worry
> about synchronization if you need multiple getAtttribute or setAttribute
> operations to be atomic.

It is worth noting that it may be necessary to synchronize access to the
objects that have their ref stored in the session object as well in some
cases.

> If you do end up wanting to synchronize, seems to me that synchronizing on
> the session is fine. There have been discussions about this, too. Not sure
> why, because how many threads will ever be competing for it?

Yep.

KISS is good.

Arne

wrote :
> In a JSP/Servlet application, what exactly constitutes a user session?
> If I have an application open and I open a new browser window at one
> of the pages in the app would this create 2 sessions or still one?
> Basically, I was trying to find out if I need to synchronize access to
> any session variables in servlet code or that is not necessary.

AFAIK if the "application" running in the web browser opens a new
window, then that window becoms a child of the parent window. You can
in fact "contact" the parent form the child and the child from the
parent.

As such the child window shares the same session information.

If the user opens a new window manually from the OS, then it depends on
the browser implementation and should not be relied on as being
consistent.

--
Wojtek