I'm currently experiencing an interesting problem.
My Situation: - I am currently developing a web service (I'm using VAADIN for programming with JAVA in eclipse)
- My database behind is java derby
- I am using hibernate
- I'm currently deploying it on Tomcat v7.0
My Problem: - When I change something in my code (doesn't matter what), the server should reload it without the need of being restarted - I guess that's the overall expected behaviour
- The server reloads the application successfull, but if I try to click on something (so after the reloading) I get an error
Cause: org.hibernate.exception.GenericJDBCException: Could not open connection] with root cause
ERROR XSDB6: Another instance of Derby may have already booted the database C:\HTML-Ausgabe\database\DocumentDB.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
My Thoughts on this It seems that somehow on the reloading process the connection/context to hibernate doesnt get destroyed/closed and so the error occures when the server tries to reconnect to the database
My Code I have a class, called Hibernate Listener:
My (VAADIN) web.xml, in which I added a "listener" for the upper shown HibernateListener (check the text at listener):
I did research, posted also on the hibernate forum (still without even a single answer ) and now did not find a matching thread yet on this website. So I hope I didn't do something wrong.
If anyone of you could help me somehow, I would be really happy. Currently I dont know what to change to stop this error happening. And, of course, I cant always restart the whole server later when my application is on the internet, if I change one line of code.
Thanks a lot for every answer and thought that you're sharing with me.
Tomcat has a long history of difficulties when it comes to hot-updating stuff that depends on static data such as the ORM base environment. A related issue is its regrettable tendency to leak PermGen space, which really becomes apparent when using ORMs.
Because of this, you are better off using the Tomcat control panel to terminate the old copy of the app, deploy the updated copy, and start it.
Or just do what I do, which is restart Tomcat, which is generally less trouble. Tomcat can restart fairly rapidly in most cases.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
Put a gun against his head, pulled my trigger, now he's dead, that tiny ad sure bled