There must be something blatent that I'm missing. By my understanding, the movement of source that I'm attempting (below) is completely valid, but it is not. (This is the only change that occurs. This code is within a jsp.)

The following works



The following throws an error




Hibernate version:
version 2.1.7c, 24.11.2004

Full stack trace of any exception that occurs:
09:28:41,273 ERROR StandardWrapper[:jsp]:269 - Servlet.service() for servlet jsp threw exception
net.sf.hibernate.HibernateException: Session is closed
at net.sf.hibernate.impl.SessionImpl.connection(SessionImpl.java:3327)
at net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:66)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:779)
at net.sf.hibernate.hql.QueryTranslator.iterate(QueryTranslator.java:864)
at net.sf.hibernate.impl.SessionImpl.iterate(SessionImpl.java:1618)
at net.sf.hibernate.impl.QueryImpl.iterate(QueryImpl.java:27)
at org.apache.jsp.notebook.docgroup_005fedit_jsp._jspService(org.apache.jsp.notebook.docgroup_005fedit_jsp:309)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:325)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:245)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)


(I don't think the other info is relevant...)

Wow. I'm REALLY gonna go out on a limb here and venture a guess... but I think your session is closed! Usually Hibernate's exceptions are telling you exactly what the problem is (though sometimes I don't speak the same version of english the Hibernate authors do!).

My guess is that you don't have an open session. How are you aquiring the session? Since you're doing this in a JSP (and shame on you for not using a decent MVC framework to get the code out of your page - Tapestry, JSF, Struts, Spring, WebWork, take your pick!) I recommend trying the Open Session in View pattern. Search the hibernate site and forums and you'll find plenty of information on this pattern.

I do have an open session. You'll note two code fragments, and my statement that "this is the only change that occurs" (in the program), and that 'one works, the other does not' - of course I have a session active, otherwise neither would work.

On an unrelated note, I see nothing wrong with using a jsp for testing. But thank you nonetheless.

Gotta concur with cardsharp here. Looks like you need to sit down and properly anayse your code with a debugger before posting here again.

missed that: autoinstantiate inside a static util class, and using threadlocal.


There is nothing that can close that session in the code. I've switched (alternated) between the two fragments at least 10 times. No other part of the code was changed. The first always displays properly, the second always throws that exception.

Just to re-iterate - this is in fact working. However, changing that one part that I listed, exactly as listed, causes the exception.


by this example, the following will work, and then break:

works:
String a = "a";
String ab = a. concat("b");

breaks:
//String a = ;
String ab = "a". concat("b");

So, I assume that your hbSession is actually the ThreadLocal implementation and not a direct reference to a Hibernate Session?

Seems to me like the two fragments of code should compile down to the same thing... but perhaps since you're using the ThreadLocal, it's binding the session to the thread differently. I'd debug it to see what's happening to your thread value between the calls.

the lawlessness appears to have been the prelude to the unfortunate and terrible sounding death of a hard disk.

My condolences.

i've got quite the same problem (Session is closed) ...

The code works 90% perfect ... and directly after starting the WebServer (Tomcat or WebSphere) the same error occurs ... after pressing "F5" everything works fine and the problem is gone ...

Note: Hibernate is correctly initialized (i can see that in the logs) and a Hibernate-Session is opened always the same "generic" way using the ThreadLocal-Pattern ... and it's NOT the first db-query that doesn't work ...

I'm quite sure, that hibernate isn't the problem ... but at the moment i'm not quite sure what the problem is ... (the problem occurs in Tomcat and Websphere) ...

gtx
curio

well ... you know the days where nothing will work? everything seems to be perfectly right but it simply doesn't work? ... and you don't see the damn forrest between all the trees?

Well .. today is such a day ... calling "Session.close()" at a point where i better should'nt have done it is a really good explanation for the Exception ;)

Just for protocol: I call "Session.close" only at one central point of the application ... but i had forgotten one case ...

gtx
curio