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]
