My question is about this answer here that seems to work for my case (tomcat). However I see that it uses a newSingleThreadScheduledExecutor(). In my case the periodical task that has to be executed could be long lasting and I want to make sure that it will not block my web site until it has completed (run as a separated Thread). In addition I want to make sure that my task Runnable will be able to share mySQL connection pool (through hibernate) that the web site is using.
So, is that still the correct approach or do I have to use something else?
I want to make sure that it will not block my web site until it has
completed (run as a separated Thread)
The HTTP connector thread pool and the thread pool allocated to run timer tasks are different. They are not dependent on each other and will not block your website.
In addition I want to make sure that my task Runnable will be able to
share mySQL connection pool (through hibernate) that the web site is
using. So, is that still the correct approach or do I have to use
something else?
Configure a common connection pool using a framework like commons DBCP and lookup the resource on the JNDI. Once you lookup that DataSource and the work on the connection has terminated, return the connection back to the pool.
The approach is fine.
Related
I didn't use any framework since it's only a little project. Now I invoke connection.close() in the destroy() method of the main servlet. But there are some problems.
I don't know when servlet.destroy() is invoked...I thought when the browser is closed is the time it's invoked,but it seems wrong.
I found out that if I don't operate the page visiting my project,after some time,destroy() is invoked,then the connection will be closed.But the project is running some code that maybe periodically write to the database,that case a exception will be thrown.
Any solutions? And I want to know when the servlet.destroy() will be invoked.
That only works if you have one shared connection.
A better solution is to use the JNDI connection pooling capability built into your servlet engine. You want to use a connection in the smallest method scope possible and return it to the pool. You'll be able to serve more clients with a small connection pool that way.
I am wondering if anyone has information on the performance overhead of adding more threads to a tomcat thread pool?
We have been seeing issues with an app of ours and everything points to an issue with tomcat adding more threads to the thread pool.Is this true? Does adding more threads to the thread pool cause a slowdown in response time?
We are running a Java REST API using Spring Boot and its embedded tomcat. If our problems are indeed caused by tomcat adding more threads to the pool, is there a way to set a minimum in Spring? According to this thread MinSpareThreads does not exist anymore. https://github.com/spring-projects/spring-boot/issues/3753
If there isn't a way to increase the number of minimum threads with Spring Embedded Tomcat, what are other tools that you use for thread pools?
Edit:
I have attached a thread profile. The profile is not of the time in question but later.
We are now able to add the both edges of configuration:
wilkinsona commented Apr 19, 2016 ->
maxThreads has always been configurable. minSpareThreads can now be configured too (see 34eb369)
Add configuration option for maxSpareThreads - (Old bug, finally fixed)
I have used MySqlDataSource for in jdbc connectivity.I have used following code
MysqlDataSource d = new MysqlDataSource();
d.setUser("user");
d.setPassword("pass");
d.setServerName("hostname.com");
d.setDatabaseName("db");
Connection c = d.getConnection();
Also i have searched there is an option of Configuring a MySQL Datasource in Apache Tomcat.
Is there any performance difference between these two? which one is best to use?
Configuring Datasource in tomcat will help you to share same data source between applications running in same tomcat. that Datasource will be managed by container (tomcat in your case).
while the Datasource created in code will be created by your application and can be used by that application only.
So if you have multiple application running on tomcat and accessing same data source, that configuring Datasource in tomcat will be good approach and have performance factor because only one data source is created and not having separate connections for each application
But if you have only single application that the first approach you have used is good one
They both use the internally the same driver, i dont think the performance is much different here, i guess if you need to access teh database only at that place and the enduser isn't supposed to use his own authentication you may use it directly from java, but if you will need the connectivity on different places it could be helpful to configure this using apache configuration, specially that if anything changes like database server, user name or whatever you don't need to get in the code to change it, this could be very important if end users have to set their own configurations.
The improvement of configuring a pool of Connections (as the one provided by tomcat) is mainly that you will actually create and close a lot less of connections.
When using a pool, when you request a Connection to a pool it will look if it has any connection already created and available for reuse and, if it has, it will provide you with it (instead of creating a new Connection, which is a heavy operation). You must still close() a Connection provided by Tomcat so Tomcat knows that it can now reuse when it is requested again.
Additionally, the advantage of the pool is that your code does not need to know the configuration data for the Connection. He just requests a Connection from a given pool and the sysadmin configures it, allowing for greater flexibility (the sysadmin does not need to know how to configure your app, just how to configure the Tomcat which is fairly more standard).
I am using Glassfish 3.1, JEE6 JPA Annotations, Hibernate provider and Derby database in my (simple) application. I seem to be having a lot of difficulties with connection pooling. Basically, my application worked fine without security, but now that I've create a security realm, I'm finding that I run of of connections no matter what size I set the pool to. Obviously, there is something that I'm doing in my code that means the connection is not being returned to the pool after the servlet request finishes.
I've seen various posting and advice on StackOverflow and have tried them all...nothing seems to work.
What I would like to know is this...How do I get logging and trace information out of Glassfish? I need to find out why it is not returning the connection to the pool. This way I hope to be able to find the source of the problem.
Many thanks!
Its always the first guess, that connections are not returned to the pool due to lack of cleaning up.
Make sure that:
close all connections you open
close all EntityManagers that you used
in every Path.
It is good practice, do
use
try
{
//open
//work
}
catch
{
//exception handling
}
finally
{
//close
}
anywhere where you handle those situations.
Side Note:
Static Analyzers like findbugs/sonar are able to detect those situations.
I have a Tomcat servlet that incorporates hibernate. It works fine normally. When the servlet starts I initialize hibernate and create a session factory. I then use this session factory to generate sessions when performing various database transactions. So far so good. My problem comes after a long period of inactivity on the servlet (say when the users go home for the night and then try to log in the next morning). Suddenly, I am unable to communicate with the databse. In the logs I see
org.hibernate.exception.JDBCConectionException: Could not execute query.
If I stop and restart Tomcat, reinitializing my servlet and rebuilding my session factory, everything works fine. It is almost like the session factory itself is timing out?
Any ideas?
Thanks,
Elliott
If I stop and restart Tomcat, reinitializing my servlet and rebuilding my session factory, everything works fine. It is almost like the session factory itself is timing out?
It's not the session factory but the connections used by the session factory (e.g. MySQL is well known to timeout connections after 8 hours of inactivity by default). Either:
use a connection pool that is able to validate connections on borrow and to renew them ~or~
increase the idle timeout on the database side
OK. Suppose I use a c3P0 connection pool. How do I specify in the hibernate.cfg.xml file that I want to "validate connections on borrow" or does it do this by default?
The various options when using C3P0 are documented in Configuring Connection Testing. My advice would be to use the idleConnectionTestPeriod parameter:
The most reliable time to test
Connections is on check-out. But this
is also the most costly choice from a
client-performance perspective. Most
applications should work quite
reliably using a combination of
idleConnectionTestPeriod and
testConnectionsOnCheckIn. Both the
idle test and the check-in test are
performed asynchronously, which leads
to better performance, both perceived
and actual.
Note that for many applications, high
performance is more important than the
risk of an occasional database
exception. In its default
configuration, c3p0 does no Connection
testing at all. Setting a fairly long
idleConnectionTestPeriod, and not
testing on checkout and check-in at
all is an excellent, high-performance
approach.
To configure C3P0 with Hibernate, be sure to read the relevant instructions (and to use the appropriate properties, and the appropriate files).