Yep, that solved it. <property name="hibernate.c3p0.max_statements">0</property>
After that prepared statements work as normal. Doesn't the hibernate.c3p0.max_statements directive help improve performance though? I mean, wouldn't it if it didn't fall over ... ;-) Thanks Martijn, I'm glad I'm not crazy and will know to be wary of it in the future. chris Martijn Brinkers wrote: > This posting also report similar problems and it was 'solved' by > disabling the statement cache. > > https://jira.jboss.org/jira/browse/JBPORTAL-1287 > > > Martijn > > On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote: > >> Sounds to me something related to the PreparedStatement cache. Do you >> use c3po? If so did you specify hibernate.c3p0.max_statements? >> >> Martijn >> >> >> On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote: >> >>> Ok, I've figured out what exactly is causing it and how to work around >>> it. I can't say why, but perhaps a resident hibernate guru will know (it >>> may even be a know issue or gotcha). First off, the quick fix. This >>> query (and variations like load(), get(), and using the criteria api) >>> cause the problem: >>> >>> Listing listing = (Listing)session.createQuery("from Listing lst >>> where lst.id=:id") >>> .setLong("id", Long.valueOf(sListingId)).uniqueResult(); >>> >>> This works as expected: >>> >>> Listing listing = (Listing)session.createQuery("from Listing lst >>> where lst.id=" + sListingId) >>> .uniqueResult(); >>> >>> It seems to come down to how hibernate handles the query results when >>> the query is formed with a "raw" HQL string vs something like get(), >>> load(), the criteria api, or using query parameters as I was initially >>> doing. It also has something to do with the field being queried and >>> seems to happen only on fields that exist in each of the tables. In my >>> case the abstract super class Listing has the PK field "id", and the 2 >>> subclasses also have a PK field named "id." Querying by any method other >>> than "constructed strings" leads to the issue, while querying on another >>> field in the super class, whose name is unique to that class, works fine. >>> >>> So the BIG question is why in the world does it work the first time and >>> continue to work until the value one queries by changes? >>> >>> I'd also like to know if anyone has seen this before, and/or if it's a >>> known issue. I'm using a slightly outdated version of hibernate >>> (3.2.2.ga) and for all I know this may be fixed in more recent versions. >>> My wrists are shot so I'll try tomorrow. If anyone knows of this or gets >>> interested/bored enough to try it, please let me know. >>> >>> Thanks tons for all of your input. >>> >>> Sincerely, >>> Chris Lewis >>> >>> Chris Lewis wrote: >>> >>>> Hello, >>>> >>>> I have a dispatcher that uses a hibernate session. The dispatcher is >>>> auto bound and receives the session in the constructor. I'm using >>>> tapestry-hibernate so that session instance is a proxy that gets the >>>> real session for the current thread (right?). Now in testing my >>>> dispatcher, I give it a url like: >>>> >>>> /MyContext/?limg=2 >>>> >>>> The dispatcher looks for "limg" and if found, queries the session >>>> assuming that its value is the PK of a mapped entity. When I trigger the >>>> dispatcher for the first time it works fine. If I refresh the page, >>>> fine. If I change the value to something else, say 3, then it breaks >>>> with a org.hibernate.InstantiationException: >>>> >>>> Cannot instantiate abstract class or interface: com.mypackage.data.Listing >>>> >>>> If I change the value back to 2, the same thing happens! "Listing" is an >>>> abstract class mapped as a super class entity via: >>>> >>>> @Entity >>>> @Inheritance(strategy = InheritanceType.JOINED) >>>> >>>> Any clue what's going on here? Two things are perplexing me: >>>> >>>> 1) Querying mapped super classes is legal, and I in fact the same thing >>>> on my Index page with no problem. >>>> 2) The query works the first time, but as soon as the id changes it is >>>> forever broken until I restart the container. >>>> >>>> Thanks in advance! >>>> >>>> chris >>>> >>>> >>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- http://thegodcode.net
