Re: Does Tomcat JDBC Connection Pool reset autocommit on closed connections?
On Mon, 15 Mar 2021 11:25:17 -0500 Christopher Schultz wrote > Alex, > > On 3/13/21 10:20, My Subs wrote: > > On Fri, 12 Mar 2021 20:24:48 -0500 Christopher Schultz > > wrote > > > > > > > > Alex, > > > > > > On 3/12/21 16:32, My Subs wrote: > > > > On Fri, 12 Mar 2021 02:35:27 -0500 Mark Thomas > > wrote > > > > > > > > > On 12/03/2021 03:57, My Subs wrote: > > > > > > Hello, > > > > > > > > > > > > I'm using Tomcat 10.0.0. Suppose I call setAutoCommit(false) > > on a connection obtained from a Tomcat JDBC Connection Pool. Then I do > > some stuff with the connection, call commit() or rollback() and finally > > call close() on it without ever calling setAutocommit(true). > > > > > > > > > > > > What will the autocommit state of that connection be, the next > > time the pool gives it to my code? Will it be in the same state I left > > it, that is, with autocommit set to false, or will it be reverted back to > > the default state (autocommit set to true)? > > > > > > > > > > The simplest way to be sure is to run a test with a pool size of > > 1. > > > > > > > > > > A quick look at the code (I might have missed something) > > suggests that > > > > > if defaultAutoCommit is configured then it will be reset to that > > default > > > > > value. Otherwise it will be unchanged from when the connection > > was > > > > > returned to the pool. > > > > > > > > > > Mark > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > Hi Mark, > > > > > > > > Thanks for your comment. I found this on > > https://tomcat.apache.org/tomcat-10.0-doc/jdbc-pool.html: > > > > > > > > "The only state the pool itself inserts are defaultAutoCommit, > > defaultReadOnly, defaultTransactionIsolation, defaultCatalog if these are > > set. These 4 properties are only set upon connection creation. Should > > these properties be modified during the usage of the connection, the pool > > itself will not reset them." > > > > > > > > It seems to say that connections will not be reverted back to the > > default auto-commit state even if defaultAutoCommit is set. Given your > > reading of the source code, might it be that the docs are wrong? > > > > > > I think the docs can easily be misunderstood. > > > > > > I don't use the tomcat-pool but I do use the *other* pool provided by > > > Tomcat and they are generally expected to be (mostly) interchangeable. > > > > > > A connection pool which doesn't reset the auto-commit state on > > > connection-return operation would IMO be considered very badly broken. > > > > > > tomcat-pool allows you to NOT specify a default in which case > > > Connection.setAutoCommit() will never be called *at all* by the pool. > > > That seems like reasonable behavior (don't mess with my stuff!), but > > it > > > means that the application will *always* have to reset the auto-commit > > > state to a known value *every single time* a connection is borrowed. > > > > > > Since the whole point of the pool is to manage this kind of thing, I > > > would argue that having defaultAutoCommit NOT set to anything would be > > > considered very bad practice. > > > > > > If you set defaultAutoCommit="true", you should expect that, when your > > > connections are returned to the pool, that setAutoCommit(true) will be > > > called every single time the connection is returned to the pool -- > > > usually by the application calling Connection.close(). > > > > > > Are you worried about a particular use-case or are you just being > > > extra-vigilant? Or are you observing some unexpected behavior? > > > > > > -chris > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > Hi Chris, > > > > I’m trying to wrap my head around on whether I can end transaction blocks > > in a try clause with a simple call to commit(). That would be the case if > > the pool resets the auto-commit state to the value of defaultAutoCommit. > > Try blocks would end with commit(), catch blocks with rollback(), and the > > pool takes care of setting auto-commit back to true. > > > > On the other hand, if as the docs say, “the pool itself will not reset” > > the state of connection attributes like auto-commit, then I’d need to tack > > to every try/catch a finally clause having
small error in log documentation
Last sentence of Introduction on https://tomcat.apache.org/tomcat-9.0-doc/logging.html If it used directly or indirectly by your logging library then elements of it will be shared across web applications because it is loaded by the system class loader. I think in needs to be "If it is used"
Re: Keeping a session active with ajax
I was able to warm-up HttpSession by adding `fetch('...', {cache:
"no-store"})` to JS code
So there should be no problems with AJAX :)
On Tue, 16 Mar 2021 at 01:45, Martin Grigorov wrote:
>
> Chris,
>
> On Mon, Mar 15, 2021, 18:28 Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > Martin,
> >
> > On 3/15/21 04:08, Martin Grigorov wrote:
> > > Hi Maxim,
> > >
> > > On Mon, Mar 15, 2021 at 9:46 AM Maxim Solodovnik
> > > wrote:
> > >
> > >> Maybe offtopic
> > >> but websocket requests seems to not warming up the HttpSession
> > >>
> > >
> > > The websocket messages do not bring the JSESSIONID cookie/request
> > parameter
> > > and there is no way to lookup the http session from the web container
> > > (Tomcat).
> > > Wicket creates a copy of the HttpSession at WebSocket connection creation
> > > time and uses it until the closing of the connection.
> > > So, yes, the real http session may expire if you use only websocket based
> > > communication.
> >
> > Yes, but that's not AJAX, as the OP mentioned. Perhaps "AJAX" just means
> > "communication using javascript without 'traditional' navigation".
> >
>
> Did you read my first answer and Maxim's email?
>
>
> > Thanks,
> > -chris
> > >> Tomcat 9.0.44
> > >> Wicket 9.2.0 :)
> > >>
> > >> On Mon, 15 Mar 2021 at 14:43, Martin Grigorov
> > >> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Which version of Tomcat ?
> > >>>
> > >>> On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm
> > >>> wrote:
> > >>>
> > In my app a logged in user will access a page. But then all of the
> > interaction on the page is done back and forth with ajax calls to the
> > server. The ajax activities within the page could last well over the
> > >> 30
> > minute session timeout. Even though the user has been actively working
> > for 30-45 minutes with lots of server calls, all of a sudden they
> > >> aren't
> > logged in any more. The ajax calls are definitely successfully
> > accessing the session since the ajax APIs utilize the logged on user,
> > roles, etc. They just aren't pinging the keep-alive bit in the
> > session
> > for some reason. I'm not really sure what would be different in the
> > calls from a regular page call from the browser vs an ajax call. They
> > both make a request that goes to a servlet or jsp and they both get
> > response data back from tomcat. But the session times out if I don't
> > >> do
> > a real page call. What am I missing?
> >
> > >>>
> > >>> Nothing!
> > >>> Any request that uses the HttpSession
> > >>> (HttpServletRequest.getHttpSession(true)) will "touch" the session and
> > >>> update its "lastUsed" time, so it should not time out during active
> > usage
> > >>> of the application.
> > >>> There must be something else that invalidates the http session.
> > >>>
> > >>>
> >
> > I really don't want to change the 'inactivity' timeout. I just need
> > to
> > figure out how to tell tomcat with all of the ajax calls that the
> > session is still very active. Is there an easy solution?
> >
> > Thx
> >
> > Jerry
> >
> > BTW... TC 8.5
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Maxim
> > >>
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > >> For additional commands, e-mail: users-h...@tomcat.apache.org
> > >>
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
--
Best regards,
Maxim
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: module muddle
A little late in responding to Mark's questions. Been on a short
walk-about.
On 3/11/21 12:17 PM, Mark Thomas wrote:
On 11/03/2021 19:08, Rob Sargent wrote:
I've started getting this error, though I've been running fine since
days of "localhost" issue help.
class org.apache.tomcat.dbcp.dbcp2.BasicDataSource cannot be cast to
class org.apache.tomcat.jdbc.pool.DataSource
(org.apache.tomcat.dbcp.dbcp2.BasicDataSource is in unnamed module
of loader 'app'; org.apache.tomcat.jdbc.pool.DataSource is in
unnamed module of loader
org.apache.catalina.loader.ParallelWebappClassLoader @33c9efd6)
I'm most confused by the "'app'" loader. Who's is that? I doesn't
look like a TC thing. I have a package called "app" which includes
the main() of my embedded server.
Apologies as I'm not fully up on the modules notion and was
blissfully getting by without dealing with that. Until now. You can
find me over in the Java Organization section of hell.
Which database connection pool do you want to use?
Tomcat's package renamed copy of Apache Commons DBCP
or
Tomcat's own JDBC Pool?
(there isn't much to choose between them these days).
How is the DataSource defined?
My context.xml is as follows
Do you know what code is triggering the failing cast?
public DataSource getDataSource(String dbname) {
DataSource lookupDS = null;
try {
InitialContext ic = new InitialContext();
Context sgsContext = (Context) ic.lookup("java:/comp/env");
//*** this next line is the cast which blows up.
lookupDS = (org.apache.tomcat.jdbc.pool.DataSource)
sgsContext.lookup("jdbc/sgsdb/"+dbname);
}
catch (javax.naming.NamingException ne) {
lookupDS = null;
log(ne.getMessage()); //TODO
}
return lookupDS;
}
The app loader is one of the class loaders in the standard Java class
loader hierarchy. I forget the exact details. Google should be able to
tell you that.
Got it.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Embedded Tomcat 9.0.43 : WINDOW_UPDATE not sent when receiving http2 requests over unknown url
On 11/03/2021 20:01, Doug Whitfield wrote: I am working on a fix which I expect to be in the releases due out in ~1 month's time. Thanks Mark! Is there any chance of a patch being available before then that we might be able to backport locally? It is fixed in 10.0.x, 9.0.x and 8.5.x now. It isn't a simple back-port. There were quite a few related changes and associated refactoring. If you want to test locally, I suggest building HEAD rather than back-porting commits. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Keeping a session active with ajax
Chris, On Mon, Mar 15, 2021, 18:28 Christopher Schultz < ch...@christopherschultz.net> wrote: > Martin, > > On 3/15/21 04:08, Martin Grigorov wrote: > > Hi Maxim, > > > > On Mon, Mar 15, 2021 at 9:46 AM Maxim Solodovnik > > wrote: > > > >> Maybe offtopic > >> but websocket requests seems to not warming up the HttpSession > >> > > > > The websocket messages do not bring the JSESSIONID cookie/request > parameter > > and there is no way to lookup the http session from the web container > > (Tomcat). > > Wicket creates a copy of the HttpSession at WebSocket connection creation > > time and uses it until the closing of the connection. > > So, yes, the real http session may expire if you use only websocket based > > communication. > > Yes, but that's not AJAX, as the OP mentioned. Perhaps "AJAX" just means > "communication using javascript without 'traditional' navigation". > Did you read my first answer and Maxim's email? > Thanks, > -chris > >> Tomcat 9.0.44 > >> Wicket 9.2.0 :) > >> > >> On Mon, 15 Mar 2021 at 14:43, Martin Grigorov > >> wrote: > >>> > >>> Hi, > >>> > >>> Which version of Tomcat ? > >>> > >>> On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm > >>> wrote: > >>> > In my app a logged in user will access a page. But then all of the > interaction on the page is done back and forth with ajax calls to the > server. The ajax activities within the page could last well over the > >> 30 > minute session timeout. Even though the user has been actively working > for 30-45 minutes with lots of server calls, all of a sudden they > >> aren't > logged in any more. The ajax calls are definitely successfully > accessing the session since the ajax APIs utilize the logged on user, > roles, etc. They just aren't pinging the keep-alive bit in the > session > for some reason. I'm not really sure what would be different in the > calls from a regular page call from the browser vs an ajax call. They > both make a request that goes to a servlet or jsp and they both get > response data back from tomcat. But the session times out if I don't > >> do > a real page call. What am I missing? > > >>> > >>> Nothing! > >>> Any request that uses the HttpSession > >>> (HttpServletRequest.getHttpSession(true)) will "touch" the session and > >>> update its "lastUsed" time, so it should not time out during active > usage > >>> of the application. > >>> There must be something else that invalidates the http session. > >>> > >>> > > I really don't want to change the 'inactivity' timeout. I just need > to > figure out how to tell tomcat with all of the ajax calls that the > session is still very active. Is there an easy solution? > > Thx > > Jerry > > BTW... TC 8.5 > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > >> > >> > >> > >> -- > >> Best regards, > >> Maxim > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Keeping a session active with ajax
On 3/15/2021 2:42 AM, Martin Grigorov wrote: Hi, Which version of Tomcat ? I'm running Tomcat 8.5.30 on AWS Linux 2. On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm wrote: In my app a logged in user will access a page. But then all of the interaction on the page is done back and forth with ajax calls to the server. The ajax activities within the page could last well over the 30 minute session timeout. Even though the user has been actively working for 30-45 minutes with lots of server calls, all of a sudden they aren't logged in any more. The ajax calls are definitely successfully accessing the session since the ajax APIs utilize the logged on user, roles, etc. They just aren't pinging the keep-alive bit in the session for some reason. I'm not really sure what would be different in the calls from a regular page call from the browser vs an ajax call. They both make a request that goes to a servlet or jsp and they both get response data back from tomcat. But the session times out if I don't do a real page call. What am I missing? Nothing! Any request that uses the HttpSession (HttpServletRequest.getHttpSession(true)) will "touch" the session and update its "lastUsed" time, so it should not time out during active usage of the application. There must be something else that invalidates the http session. I really don't want to change the 'inactivity' timeout. I just need to figure out how to tell tomcat with all of the ajax calls that the session is still very active. Is there an easy solution? Thx Jerry BTW... TC 8.5 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Keeping a session active with ajax
Martin, On 3/15/21 04:08, Martin Grigorov wrote: Hi Maxim, On Mon, Mar 15, 2021 at 9:46 AM Maxim Solodovnik wrote: Maybe offtopic but websocket requests seems to not warming up the HttpSession The websocket messages do not bring the JSESSIONID cookie/request parameter and there is no way to lookup the http session from the web container (Tomcat). Wicket creates a copy of the HttpSession at WebSocket connection creation time and uses it until the closing of the connection. So, yes, the real http session may expire if you use only websocket based communication. Yes, but that's not AJAX, as the OP mentioned. Perhaps "AJAX" just means "communication using javascript without 'traditional' navigation". Thanks, -chris Tomcat 9.0.44 Wicket 9.2.0 :) On Mon, 15 Mar 2021 at 14:43, Martin Grigorov wrote: Hi, Which version of Tomcat ? On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm wrote: In my app a logged in user will access a page. But then all of the interaction on the page is done back and forth with ajax calls to the server. The ajax activities within the page could last well over the 30 minute session timeout. Even though the user has been actively working for 30-45 minutes with lots of server calls, all of a sudden they aren't logged in any more. The ajax calls are definitely successfully accessing the session since the ajax APIs utilize the logged on user, roles, etc. They just aren't pinging the keep-alive bit in the session for some reason. I'm not really sure what would be different in the calls from a regular page call from the browser vs an ajax call. They both make a request that goes to a servlet or jsp and they both get response data back from tomcat. But the session times out if I don't do a real page call. What am I missing? Nothing! Any request that uses the HttpSession (HttpServletRequest.getHttpSession(true)) will "touch" the session and update its "lastUsed" time, so it should not time out during active usage of the application. There must be something else that invalidates the http session. I really don't want to change the 'inactivity' timeout. I just need to figure out how to tell tomcat with all of the ajax calls that the session is still very active. Is there an easy solution? Thx Jerry BTW... TC 8.5 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Best regards, Maxim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does Tomcat JDBC Connection Pool reset autocommit on closed connections?
Alex, On 3/13/21 10:20, My Subs wrote: On Fri, 12 Mar 2021 20:24:48 -0500 Christopher Schultz wrote > > Alex, > > On 3/12/21 16:32, My Subs wrote: > > On Fri, 12 Mar 2021 02:35:27 -0500 Mark Thomas wrote > > > > > On 12/03/2021 03:57, My Subs wrote: > > > > Hello, > > > > > > > > I'm using Tomcat 10.0.0. Suppose I call setAutoCommit(false) on a connection obtained from a Tomcat JDBC Connection Pool. Then I do some stuff with the connection, call commit() or rollback() and finally call close() on it without ever calling setAutocommit(true). > > > > > > > > What will the autocommit state of that connection be, the next time the pool gives it to my code? Will it be in the same state I left it, that is, with autocommit set to false, or will it be reverted back to the default state (autocommit set to true)? > > > > > > The simplest way to be sure is to run a test with a pool size of 1. > > > > > > A quick look at the code (I might have missed something) suggests that > > > if defaultAutoCommit is configured then it will be reset to that default > > > value. Otherwise it will be unchanged from when the connection was > > > returned to the pool. > > > > > > Mark > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > Hi Mark, > > > > Thanks for your comment. I found this on https://tomcat.apache.org/tomcat-10.0-doc/jdbc-pool.html: > > > > "The only state the pool itself inserts are defaultAutoCommit, defaultReadOnly, defaultTransactionIsolation, defaultCatalog if these are set. These 4 properties are only set upon connection creation. Should these properties be modified during the usage of the connection, the pool itself will not reset them." > > > > It seems to say that connections will not be reverted back to the default auto-commit state even if defaultAutoCommit is set. Given your reading of the source code, might it be that the docs are wrong? > > I think the docs can easily be misunderstood. > > I don't use the tomcat-pool but I do use the *other* pool provided by > Tomcat and they are generally expected to be (mostly) interchangeable. > > A connection pool which doesn't reset the auto-commit state on > connection-return operation would IMO be considered very badly broken. > > tomcat-pool allows you to NOT specify a default in which case > Connection.setAutoCommit() will never be called *at all* by the pool. > That seems like reasonable behavior (don't mess with my stuff!), but it > means that the application will *always* have to reset the auto-commit > state to a known value *every single time* a connection is borrowed. > > Since the whole point of the pool is to manage this kind of thing, I > would argue that having defaultAutoCommit NOT set to anything would be > considered very bad practice. > > If you set defaultAutoCommit="true", you should expect that, when your > connections are returned to the pool, that setAutoCommit(true) will be > called every single time the connection is returned to the pool -- > usually by the application calling Connection.close(). > > Are you worried about a particular use-case or are you just being > extra-vigilant? Or are you observing some unexpected behavior? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Hi Chris, I’m trying to wrap my head around on whether I can end transaction blocks in a try clause with a simple call to commit(). That would be the case if the pool resets the auto-commit state to the value of defaultAutoCommit. Try blocks would end with commit(), catch blocks with rollback(), and the pool takes care of setting auto-commit back to true. On the other hand, if as the docs say, “the pool itself will not reset” the state of connection attributes like auto-commit, then I’d need to tack to every try/catch a finally clause having setAutoCommit(true). But this would be unnecessary boilerplate if, as Mark says —and you believe should be the case—, the pool does effect the reset. I’d rather not bloat the code, hence my question. I guess that puts me in the extra-vigilant camp. It should work like any other connection pool you have used in the past. Just be sure to set defaultAutoCommit="true" in your configuration. Then it will *always* set autocommit=true when you return your connections to the pool. Just some more food for thought: https://blog.christopherschultz.net/2009/03/16/properly-handling-pooled-jdbc-connections/ -chris
Re: Keeping a session active with ajax
Hi Maxim, On Mon, Mar 15, 2021 at 9:46 AM Maxim Solodovnik wrote: > Maybe offtopic > but websocket requests seems to not warming up the HttpSession > The websocket messages do not bring the JSESSIONID cookie/request parameter and there is no way to lookup the http session from the web container (Tomcat). Wicket creates a copy of the HttpSession at WebSocket connection creation time and uses it until the closing of the connection. So, yes, the real http session may expire if you use only websocket based communication. Martin P.S. Congrats for Apache OpenMeetings 6.0! > > Tomcat 9.0.44 > Wicket 9.2.0 :) > > On Mon, 15 Mar 2021 at 14:43, Martin Grigorov > wrote: > > > > Hi, > > > > Which version of Tomcat ? > > > > On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm > > wrote: > > > > > In my app a logged in user will access a page. But then all of the > > > interaction on the page is done back and forth with ajax calls to the > > > server. The ajax activities within the page could last well over the > 30 > > > minute session timeout. Even though the user has been actively working > > > for 30-45 minutes with lots of server calls, all of a sudden they > aren't > > > logged in any more. The ajax calls are definitely successfully > > > accessing the session since the ajax APIs utilize the logged on user, > > > roles, etc. They just aren't pinging the keep-alive bit in the session > > > for some reason. I'm not really sure what would be different in the > > > calls from a regular page call from the browser vs an ajax call. They > > > both make a request that goes to a servlet or jsp and they both get > > > response data back from tomcat. But the session times out if I don't > do > > > a real page call. What am I missing? > > > > > > > Nothing! > > Any request that uses the HttpSession > > (HttpServletRequest.getHttpSession(true)) will "touch" the session and > > update its "lastUsed" time, so it should not time out during active usage > > of the application. > > There must be something else that invalidates the http session. > > > > > > > > > > I really don't want to change the 'inactivity' timeout. I just need to > > > figure out how to tell tomcat with all of the ajax calls that the > > > session is still very active. Is there an easy solution? > > > > > > Thx > > > > > > Jerry > > > > > > BTW... TC 8.5 > > > > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > -- > Best regards, > Maxim > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Keeping a session active with ajax
Maybe offtopic but websocket requests seems to not warming up the HttpSession Tomcat 9.0.44 Wicket 9.2.0 :) On Mon, 15 Mar 2021 at 14:43, Martin Grigorov wrote: > > Hi, > > Which version of Tomcat ? > > On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm > wrote: > > > In my app a logged in user will access a page. But then all of the > > interaction on the page is done back and forth with ajax calls to the > > server. The ajax activities within the page could last well over the 30 > > minute session timeout. Even though the user has been actively working > > for 30-45 minutes with lots of server calls, all of a sudden they aren't > > logged in any more. The ajax calls are definitely successfully > > accessing the session since the ajax APIs utilize the logged on user, > > roles, etc. They just aren't pinging the keep-alive bit in the session > > for some reason. I'm not really sure what would be different in the > > calls from a regular page call from the browser vs an ajax call. They > > both make a request that goes to a servlet or jsp and they both get > > response data back from tomcat. But the session times out if I don't do > > a real page call. What am I missing? > > > > Nothing! > Any request that uses the HttpSession > (HttpServletRequest.getHttpSession(true)) will "touch" the session and > update its "lastUsed" time, so it should not time out during active usage > of the application. > There must be something else that invalidates the http session. > > > > > > I really don't want to change the 'inactivity' timeout. I just need to > > figure out how to tell tomcat with all of the ajax calls that the > > session is still very active. Is there an easy solution? > > > > Thx > > > > Jerry > > > > BTW... TC 8.5 > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > -- Best regards, Maxim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Keeping a session active with ajax
Hi, Which version of Tomcat ? On Mon, Mar 15, 2021 at 8:25 AM Jerry Malcolm wrote: > In my app a logged in user will access a page. But then all of the > interaction on the page is done back and forth with ajax calls to the > server. The ajax activities within the page could last well over the 30 > minute session timeout. Even though the user has been actively working > for 30-45 minutes with lots of server calls, all of a sudden they aren't > logged in any more. The ajax calls are definitely successfully > accessing the session since the ajax APIs utilize the logged on user, > roles, etc. They just aren't pinging the keep-alive bit in the session > for some reason. I'm not really sure what would be different in the > calls from a regular page call from the browser vs an ajax call. They > both make a request that goes to a servlet or jsp and they both get > response data back from tomcat. But the session times out if I don't do > a real page call. What am I missing? > Nothing! Any request that uses the HttpSession (HttpServletRequest.getHttpSession(true)) will "touch" the session and update its "lastUsed" time, so it should not time out during active usage of the application. There must be something else that invalidates the http session. > > I really don't want to change the 'inactivity' timeout. I just need to > figure out how to tell tomcat with all of the ajax calls that the > session is still very active. Is there an easy solution? > > Thx > > Jerry > > BTW... TC 8.5 > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Keeping a session active with ajax
In my app a logged in user will access a page. But then all of the interaction on the page is done back and forth with ajax calls to the server. The ajax activities within the page could last well over the 30 minute session timeout. Even though the user has been actively working for 30-45 minutes with lots of server calls, all of a sudden they aren't logged in any more. The ajax calls are definitely successfully accessing the session since the ajax APIs utilize the logged on user, roles, etc. They just aren't pinging the keep-alive bit in the session for some reason. I'm not really sure what would be different in the calls from a regular page call from the browser vs an ajax call. They both make a request that goes to a servlet or jsp and they both get response data back from tomcat. But the session times out if I don't do a real page call. What am I missing? I really don't want to change the 'inactivity' timeout. I just need to figure out how to tell tomcat with all of the ajax calls that the session is still very active. Is there an easy solution? Thx Jerry BTW... TC 8.5 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
