Hi.
Hi.
The recommendation on this forum is to not use "top posting", but to keep the flow of
conversation natural, and respond below the question to which your question refers.
See http://tomcat.apache.org/lists.html, "Important", 6)
I have modified you latest post accordingly below.
chedana jayasinghe wrote:
On Tue, Jun 23, 2015 at 2:46 PM, André Warnier <a...@ice-sa.com> wrote:
chedana jayasinghe wrote:
In my web application, in a jsp there is a javascript which sends request
to a servlet every twenty seconds, so it kills my applications user idle
time tracking by resetting the lastAccessed time in session. the funny
thing is lastAccessed time doesn't get updated in tomcat 6 and my
applications idle time tracking works fine in it, but in 7 it gets updated
and kills that functionality of the application . so I'm little bit
confused about the changes in the session tracking of tomcat 6 and tomcat
7.
I don't know what happened in Tomcat 6 as compared to what happens in
other versions.
But from a purely logical point of view, I would tend to think that, from
the server point of view, whether a request comes from the user pressing a
button or from a javascript module in a page sending a request, does not
make a difference : the application has been accessed, so the "last
accessed time" should be updated.
That is probably the point even, of many such javascript snippets out
there in the wild.
So again from a purely logical point of view, if Tomcat 6 then did not
update the last access time, that would sound more like a bug, that was
corrected later.
Maybe the fact that it updates this or not, depends on whether the
application that is called retrieves the session or not, and if so you may
have control over it, by making sure that whatever your javascript calls,
it does /not/ retrieve the session.
Caveat : I do not really /know/ how it works, so there is a lot of
speculation here.
> I just put a debug point an checked. In tomcat 6,the request comes to the
> servlet with a null session,but in tomcat 7 and later versions the valid
> session is there in the request
>
Yes, but the /call/ that contains this jsession-id, comes from the javascript that is in
the HTML page currently shown in the browser.
So the question is : why does that /call/, now, contain this jsessionid parameter, when
under Tomcat 6 it did not ?
Or to put this another way : how does the local javascript in the browser *know* this
jsession-id ?
Or in yet another way : the javascript in the browser does not /know/ if it is talking to
a Tomcat 6 or a Tomcat 7 or a Tomcat 8 server, right ? So how comes that in one case, it
sends a request /without/ a jsessionid, and in the other cases /with/ a jsessionid ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
