I'm using a singleton class for a PostgresSQL connection inside a servelet. The problem is that once it is open it works for a while (I guess until some timeout), and then it starts throwing a I/O exception. Any idea what is happening to the singleton class inside Tomcat VM?
Thanks
I have no idea. Just do the right thing and do not reinvent the wheel.
Use a DataSource. Either obtain it via JNDI, or do it yourself (I like using Spring, but if your web application is very simple, it's probably overkill).
Use a DataSource.
There's no singleton inside Tomcat; that's just the way connections work when you only have one and keep it open for a long time. It's called "timeout".
This design cannot scale. A better solution is to keep connections open for as short a time as possible. Your code should open a connection, use it, and close it in transaction scope.
You should also set up a connection pool in Tomcat.
and then it starts throwing a I/O exception
Well, what is the exception exactly?
Also, as a note, it's safe to use the same Postgres JDBC connection from multiple threads, but it is not recommended to do so.
Related
If I use JDBCTemplate, is the connection automatically closed even if i dont use try with resources (or incase I am throwing an exception in a catch block assuming some sqlexception occured) ? Is JDBCTemplate smart enough?
https://www.javatpoint.com/spring-JdbcTemplate-tutorial
This resource says:
It takes care of creation and release of resources such as creating and closing of connection object etc. So it will not lead to any problem if you forget to close the connection.
So by usnig JDBCTemplate, one can simply forget about connection closing?
Yes, you can forget about connection closing.
When you have questions about something mentioned in a tutorial, you should always check the documentation. You should definitely do that before asking here.
If you had checked the documentation, you'd have found:
3.3.1. Using JdbcTemplate
JdbcTemplate is the central class in the JDBC core package. It handles the creation and release of resources, which helps you avoid common errors, such as forgetting to close the connection. It performs the basic tasks of the core JDBC workflow (such as statement creation and execution), leaving application code to provide SQL and extract results.
It goes on, of course, so you should really click the link and read it for yourself.
The documentation is well-written, so there is no good excuse not to read it and/or reference it when in doubt.
our project is deployed on the cloud but we need to shutdown and restart tomcat7 everyday otherwise "org.hibernate.exception.JDBCConnectionException: Cannot open connection" exception will rise, please help me to resolve this.
I'm guessing that you have a leak somewhere in your code which gets a connection without returning it to the pool (via Connection.close()).
Spring's JdbcTemplate exists mainly to prevent cases like this from ever occurring.
I'd look through the code for methods which get a connection but don't call Connection.close() in a finally block.
I recently wanted to prevent connection leaks but didn't want all of spring's dependencies so I wrote a very simple JdbcTemplate here. You might consider doing the same to avoid this from happening again (or use spring's version)
The problem setup is based on a webservice (Spring/Java, Tomcat7 and MySql) where every user gets their own database, hence each request needs their own connection. As all databases are created dynamically during runtime, configuring them statically before startup is not an option.
To optimise database connection usage, an implementation of a database connection pool would be great, right?
With Java/Spring: How would I create a connection pool for dynamic databases? I am a bit struck by the lack of clean options here!
Problem: Tomcat's Connection Pool (and as far as i understand C3P0 as well) treats each new DataSource instance as a whole new connection pool -> stack-reference
Is it a good idea to create a static datasource with a generic MySql connection (without specifing the database on connection) and use a connection pool with this datasource together with adapted SQL statements?
stack-reference
What about developing a custom persistent database based datasource pool? Any experience with performance here? Any advice? Any libraries that do that?
Or would it be feasable to workaround Tomcat's DataSource problem by creating Tomcat JNDI Datasources dynamically by manipulating it's context.xml dynamically from Java?
I can't believe that there aren't more plain/simple solutions for this. Grails/Hibernate struggles with this, Java/JDBC struggles with this, ... is it such a rare use-case to separate userdata on a user basis by creating user specific databases dynamically? If so, what would be a better setup?
EDIT
Another option is the suggestion from #M.Deinum to use a single configured datasource and dynamically hotswap it for the right connection ->M.Deinum Blog and stack-reference. How does that perform with a connection pool like the ones above?
I believe that HikariCP works without having to specify a single database.
Once the databases are created in runtime, you have to create the pools also in runtime. I am afraid the spring infrastructure is not giving you any help here, as it is tuned for the usual static use case.
I'd have a map of pools:
have a Map < connectionUrlString,List< c3poPool > > map
when requesting a connection, get the corresponding c3po pool from the map
and you can get the best of both worlds, since the real connection pool for each dynamically created database is handled by a c3po instance, but you can create new instances in runtime
This works as a low-level solution. If you want to go further, you can wrap this logic into a db connection provider, and register that as a "driver". This way any part of your application requests a new connection, you can just return one connection from the existing pools (and if a totally new connection is requested, create a new pool for that).
First than all, sorry for my english, i'm improving every day.
In my experience, I had a similar situation and it was resolve with spring framework. Let me explain you how you'd solve that question.
Make a spring config file with these characteristics:
a) A resource loader: This one is the responsible of load properties from configurations files or from database, those properties will be the appropriates to establish the database connection.
b) A pool database configuration parameterized with the properties that you'll load.
Create a locator class: In this class you'll need a HashMap
Use the multi context feature of spring: The idea is assign a code to every one connection that you establish and later load that connection like an application context with spring, then in the locator class, put in the map that context and use it as frequent as you need.
I think is you follow these steps, you can create dynamic pool or database connection as you want.
I am using Hibernate with c3p0 for connection pooling. Since I am working in a multisharded database environment and the possibility of shards' downtime is a realistic use case scenario (by means external to the application at hand, e.g. someone just taking the shard down for whatever reason), I am trying to have c3p0 explicitly close the Hibernate session once it detects that the database connection is down so that I can skip the particular shard's session in my multi-shard scan.
Is there a way to configure c3p0 to notify Hibernate, by invoking Session.close() once it finds out that the connection is down so that calling Session.isOpen() can return a meaningful boolean?
RELATED: Preemptively and gracefully check that org.hibernate.Session is still connected (via c3p0)
the short answer is no, c3p0 won't help you here.
it sounds like (looking here and at your previous question) you are doing something that works at cross-purposes to c3p0, that is you are holding long-lived Sessions rather than creating Sessions on an as-needed basis and then destroying them promptly. that kind of thing is very fragile. it is the architecture Connection pools exist to avoid.
your best choice, IMO, would be "don't do that". don't ever cache Sessions at all. then ordinary Connection testing (perhaps with checkoutTimeout set too) will resolve the problem. if a shard is down, attempts to acquire a Connection will fail, and you can skip the shard if that's the best workaround.
c3p0 knows nothing whatsoever about hibernate. c3p0's author is grateful to hibernate for popularizing his (my) library, but c3p0 has no idea what a Session is, just a Connection. the only way that c3p0 could help you a little bit, in theory, would be that it could report to you an event when it notices that a database is down (which might be quite promptly or quite slowly depending on your configuration). you could respond to the event by close()ing sessions.
unfortunately, c3p0 doesn't (yet) offer hooks through which users could respond to acquisition failures. it might — that's a feature i'm thinking about adding for 0.9.6. but it doesn't now. however, it would be pretty trivial to implement something that polls your shards and closes their Sessions yourself. all c3p0 would do to notice outages would be to call DriverManager.getConnection( ... ) or dataSource.getConnection()and observe Exceptions. you can do that yourself!
i still strongly recommend the first solution, though. get rid of the long-lived Session objects.
I'm implementing Spring MVC but would like to redirect if one of my database goes offline. Is there any easy way to check this? The application uses several databases (one for authentication etc.) so I need a graceful way of handling database issues.
Thanks,
For every dataSource run something like:
new JdbcTemplate(dataSource).queryForInt("SELECT 1").
Your dataSource might be configured to test connection before returning it, so in some cases it won't even reach query when database is down. To make the code simple, wrap this code in aspect around all your controllers.
More clean but a bit less flexible solution is to use some custom exception mapper that will catch database exceptions (Spring provides nice JDBC exceptions abstraction layer) and redirect appropriately.
Try to connect to the database, and if you can't, then redirect.