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.
Related
I am trying to implement row level security so our application can enforce more stringent access control.
One of the technologies we are looking into is Oracle's Virtual Private Database, which allows row level security by basically augmenting all queries against specific tables with a where clause predicate. Since we are in a web environment, we need to set up a special context within Oracle, inside a single request's thread. We use connection pooling with a service account.
I started to look into Eclipse Link and Hibernate. Eclipse Link seems to have events that fit perfectly into this model.
This would involve us migrating from hibernate, which is not a problem, but we would then be bound to EL for these events.
Oracle seems to imply that they implement at the data source level in Web Logic product.
The context is set and cleared by the WebLogic data source code.
Question: Is it more appropriate to do this at the DataSource level with some series of events. What are the events or methods that I should pay the most attention too?
Added Question: How would I extend a connection pool to safely initialize an oracle context with some custom data? I am digging around in Apache, and it seems like extending BasicDataSource doesn't give me access to anything that would allow me to clean up the connection when Spring is done with it.
I need to set up a connection, and clean up a connection as the exit / enter the connection pool. I am hoping for an implementation that is so simple, no one can mess it up by breaking some delicate balance of products.
- Specifically we are currently using Apache Commons DBCP Basic Data Source
This would allow us to use various ways to connect to the database and still have our security enforced. But I don't see a great example or set of events to work with, and rolling my own security life cycle is never a good idea.
I eventually solved my problem by extending some of the Apache components.
First I extended org.apache.commons.pool.impl.GenericObjectPool and overrode both borrowObject() and returnObject(). I knew the type of the objects in the pool (java.sql.Connection) so I could safely cast and work with them.
Since for my case I was using Oracle VPD, I was able to set information in the Application context. I recommend you read about that in more depth. It is a little complicated and there are a lot of different options to hide or share data at various contexts level, and across RAC nodes. Start
In essence what I did was generate a nonce and use it to instantiate a session within oracle, and then set the access level of the user to a variable in that session, that the Oracle VPD policy would then read and use to do the row level filtering.
I instantiated and destroyed that information in my overridden borrowObject() and returnObject() The SQL I ran was something like this:
CallableStatement callStat =
conn.prepareCall("{call namespace.cust_ctx_pkg.set_session_id(" + Math.random() + ")}");
callStat.execute();
Note math.random() isn't a good nonce.
Next was to simply extend org.apache.commons.dbcp.BasicDataSource and set my object pool by overriding createConnectionPool(). Note that the way I did this disabled some functionality I did not need, so you may need to rewrite more or less than I did.
You can try any object level security mechanism for simplicity, like Spring Security ACL.
You will want to do this at the application layer. You will want a pre-commit hook and a post read hook.
The pre-commit hook is used to ensure that data from the client is being presented by a user authorized to modify that data. This prevents an unauthorized user from overwriting data that they shouldn't be able to access.
It's not intuitive, but the post read hook is used to keep the client from accessing data the user shouldn't be allowed to view. This happens post-view because this is being enforced at the application layer, not at the data layer. The application has no way to know if the caller is allowed to access the data until it's been retrieved from the data layer. In the post read hook you evaluate the credential on each row returned against the credential of the logged in user in order to determine whether or not access is allowed. If access is denied on any row then an exception would be raised and the data would not be returned to the client.
Application level security done in this way requires that you have a way to connect each row in a table to a permission/role required to access it and a way to evaluate a user's permissions on the server at runtime.
Hope that helps.
You will get better control by using one of the other Commons DBCP Datasources.
The Basic one is just that: basic :)
The ones in org.apache.commons.dbcp.datasources package gives you more fine-grained control.
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)
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.
The DB driver I am working with (for a sybase DB) does not implement a Connection.isValid(). What is the most efficient way I can validate a db connection using a query (or otherwise) in Java?
Libraries such as C3P0 and DBCP allow you to provide a validation query which is typically something very simple such as "select 1". Hence, you could take the same approach or simply use either of these libraries (my recommendation would be C3P0).
However, rather than testing the connection prior to executing your query you could simply attempt to execute and then retry the operation if it fails because the connection is invalid. Alternatively you could consider a non-pooled connection approach where the connection is created on-the-fly each time (e.g. such as Spring's DriverManagerDataSource).
I mostly agree with Adamski's comment about using "select 1 from table" as an efficient way of checking connectivity and using connection pooling (e.g. commons-dbcp, C3PO).
Application servers (e.g. Websphere) allow you to configure this validation for you so your applciation code doesn't have to know about it. You have the choice of always having the connection checked prior to using it, or the connection pool being validated when a new connections is created. You can also purge connections periodically in case they get stale.
If you're not running in an application server you can use Common DBCP with the properties described here:
http://commons.apache.org/dbcp/configuration.html
Or C3PO and take a look at using the idleConnectionTestPeriod property. This link talks about use with Hibernate but its still relevant for C3PO generally
http://community.jboss.org/wiki/HowToConfigureTheC3P0ConnectionPool
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.