tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ken dombeck <>
Subject Re: Thread starvation with JDBCStore
Date Thu, 15 Nov 2012 17:05:13 GMT
We will provide the patch for Tomcat 7, is that ok or should it be on master for Tomcat 8?

We won't be updating to Tomcat 7 for a month, so we won't provide the patch until we have
fully tested it.

We updated for our new messages but did not update the other languages
since we are not fluent in those. Is that OK?

What should we do about the documentation for JDBCStore? Should we say that it is deprecated
and to use DataSourceStore instead? Or leave it and update the documentation to talk about

If you are interested you can look at the preliminary changes here.

 From: Konstantin Kolinko <>
To: Tomcat Users List <> 
Sent: Tuesday, November 6, 2012 4:22 PM
Subject: Re: Thread starvation with JDBCStore
2012/11/7 ken dombeck <>:
> #1 I can definetly create a new store (JDBCRealm, DataSourceRealm), I am just not sure
of Apache wanting to support multiple implementations.

It is not a big deal. If the new implementation is better we can
deprecate the old one and remove it from future versions. I just do
not see how all issues can be solved just by patching JDBCStore.

For such components the "support" is mostly a supervision. The bug
reports and patches are usually provided by those who are actually
using the component.

> #3 Sorry, I should have mentioned that we tested all 3 options and option 1 and 3 solved
our issue. Option 2 helped a bit but was not completely fair to all threads and therefore
still allowed the background process to "hold" the lock longer than expected.

OK, feel free to submit a patch.

> #4 Increasing the expire frequency is our current short term "hack". This is a hack because
it does not remove the problem, it just reduces the frequency of the issue.
> #5 I have found several issues opened for the performance issues of expiring database
sessions. This could be a future enhancement but does not completely solve this issue.

BZ 47281 has the same idea that I mentioned,  to use a SELECT WHERE. ;)

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message