I faced a problem regarding closing a hibernate session , The problem detail is:
UI(Implemented using JSF2.1 ) hangs after doing some action many times resulting with an empty request. The cause of the problem is the hibernate session does not close after doing any database action
So my question why has this hanging happened ? why an empty request? I think when something like this happens an exception will like IllegalStateException would be thrown by hibernate API to tell you "you have a lot of sessions opened " right ?
When you don't close your Hibernate sessions and therefore do not release JDBC connections, you have what is typically called Connection leak. So, after a number of requests (depending on the size of your connection pool) the server will not be able to acquire a connection to respond your request. Actually, server will be waiting for connections to be released and be available on pool again and it will seem to be hanging.
Related
I have created a connection using connection pool in init() method of servlet and and closing / returning the connection in destroy() method. Basically idea is to use single connection for all time and for all users of application. Now my question is , If users are idle for some time say for 15 mins , does oracle trigger any error related to idle timeout (idle timeout is set to 10 mins.)? and if yes how could i prevent the same ?..
Seems like by default there is no any timeouts. See this answer for details. In short, there is no timeouts but you can configure it. Also you can configuration dead connection detection.
But if I'm not mistaken you asking if you have such an opportunity to disable it. In short: you may not do anything and everything will work as you wish. But why? You should configure such idle timeouts and dead connection detection if you don't want some user occasionally hang you application with a single connection.
It was the first point. The other one: actually, you should have a connection pool, not a single connection, in order to serve many requests concurrently.
So sorry, the answer is the following: there is no such timeouts by default but I don't understand you intentions:) Hope this helps.
I use Primefaces / JSF2. Due to a special case we use jdbc connection instead of connection pool. Every logged in user will hold one and only DB connection at a time. If a logged in user close the browser instead of a proper logout, his DB connection get held till the idle timeout (15 mins) and he cannot login again immediately within this 15 mins timeout.
Is there any way to close the user DB connection, if he closes the browser instead of logout?
No, there is no way. At least, no reliable way. You could perhaps set the session timeout to 1 minute, keep it alive with ajax polling and use HttpSessionListener#sessionDestroyed() to close the connection. But still, the whole approach is very brittle and prone to failure.
You should always acquire and close the DB resources in the shortest possible scope within the very same try-finally block as where the SQL query/queries are fired, no excuses. A Java EE web application is really not comparable to a plain Java desktop application where the enduser can just restart the buggy application itself if it crashes due to DB resource leaking.
See also:
Is it safe to use a static java.sql.Connection instance in a multithreaded system? — whilst not exactly the same problem/question as yours, the answer is very applicable in your case.
It seems to me that we have some code that is not starting a transaction yet for read-only operations our queries via JPA/Hibernate as well as straight SQL seem to work. A hibernate/jpa session would have been opened by our framework but for a few spots in legacy code we found no transactions were being opened.
What seems to end up happening is that the code usually runs as long as it does not use EntityManager.persist and EntityManager.merge. However once in awhile (maybe 1/10) times the servlet container fails with this error...
Failed to load resource: the server responded with a status of 500 (org.hibernate.exception.JDBCConnectionException: The last packet successfully received from the server was 314,024,057 milliseconds ago. The last packet sent successfully to the server was 314,024,057 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.)
As far as I can tell only the few spots in our application code that do not have transactions started before a query is made will have this problem. Does anybody else think it could be the non-transactional query running that causes this behaviour?
FYI here is our stack...
-Guice
-Guice-Persist
-Guice-Servlet
-MySql 5.1.63
-Hibernate/C3P0 4.1.4.Final
-Jetty
Yes, I think.
If you start a query without opening a transaction, this transaction will be opened automatically by the underlying layer. This connection, with an opened transaction, will be returned to the connection pool and given to another user, that will receive a connection to an already-opened transaction, and that could lead to inconsistent state.
Here in my company we had a lot of problems in the past with read-only non-transactional queries, and adjusted our framework to handle this.
Besides that, we talked to BoneCP developers and they accepted to develop a set of features to help handle this problem, like auto-rollback uncommitted transactions returned to the pool, and print a stack trace of what method forgot to commit the transaction.
This matter was discussed here:
http://jolbox.com/forum/viewtopic.php?f=3&t=98
We are having a problem with too many Oracle processes being created (over 2,000) when connections are limited to 1,100 (using C3P0)
Two questions:
What's the relationship between an Oracle process and a JDBC connection? Is one Oracle process created for each session? Is one created for every JDBC statement? No relationship at all?
Did you ever face this scenario, where you are creating more processes than JDBC connections?
Any comment would be really appreciated.
There is one session per connection. This sounds like you have a connection leak, somewhere you're opening a new connection and not closing properly. One possibility is that you open, use and close a connection inside a try block and are handling an exception in a catch, or returning early for someother reason. If so you need to make sure the connection close is done in finally or it may not happen, leaving the connection (and thus session) hanging. Opening two connections in the same scope without an explicit close in between can also do this.
I'm not familiar with C3PO so don't know how connections are handled, or where and how your 1100 limit is imposed; if it (or you) have a connection pool and the 1100 you refer to is the maximm pool size, then this doesn't sound like the issue as you'd hit the pool cap before the session cap.
You can look in v$session to confirm that all the sessions are coming from JDBC, and there isn't something else connecting.
Maybe you want to check if your server runs in dedicated or shared mode (you probably want to switch it to shared mode if you want to decrease the number of active processes).
You can check that by doing
select server from v$session
More information about process architecture
http://docs.oracle.com/cd/B19306_01/server.102/b14220/process.htm
Shared/Dedicated server mode
http://docs.oracle.com/cd/B10501_01/server.920/a96521/manproc.htm
How do I configure Hibernate so that each time I call sessionFactory.openSession() it connects with a new connection from the connection pool? The connection pool is managed by Websphere Application Server and is a JDBC Data Source.
Thanks
How do I configure Hibernate so that each time I call sessionFactory.openSession() it connects with a new connection from the connection pool?
This is the default behavior, each session will get a dedicated connection from the connection pool.
Right now, it appears that both sessions are using the same connection, because when the first session is closed (manually calling session.close()) sometimes, the other session will throw a "session closed" exception when trying to run more queries on it.
No they are not. But maybe the second connection gets released at the end of the transaction initiated for the request. Have a look at the hibernate.connection.release_mode configuration parameter, you might want to use on_close. But without more details on your transaction strategy, it's impossible to say anything.
The second session is open by a child thread which means that the child thread can keep living even after the (HTTP) request is complete.
Take my previous advice with a grain of salt, you should just not spawn unmanaged threads and I don't know how the application server will behave. I explain in this other answer what would be the right way.