Right on. So imagine Snoopy's fist shake to the sky after being
perforated by the Red Baron (Hibernate). . . ;-)
You're dealing with alot of code layers, and potentially a data issue
here (one instance you are trying to query could be represented
in the schema just differently enough to cause this error). Personally,
I start with HibernateUtils unit tests to verify Hibernate and my
low-level code first, then move to TapestryIOC outside the container to
test the services for T5 use I've coded up, then the T5 pages: I don't
do Hibernate in Dispatchers. Again, too many layers changing underneath
(no offense to anyone, just the way it is): plus, I code for
multi-frameworks.
Point issue: I got nuthin', except intuition screams session cache
hold-over (Hibernate thinks you're asking for two distinct instances but
with the
same persistent id). Architectural curiosity: why load in a dispatcher
and what benefit is there?
Chris Lewis wrote:
Padawn,
Per your suggestion I tried the get method with the exact same results:
Listing listing = (Listing)session.get(Listing.class,
Long.parseLong(sListingId));
I also changed the dispatcher so that it uses the
HibernateSessionManager to get the current session explicitly on each
request, to no avail. I fell like something simple is evading me. My
dispatcher fires before the page render dispatcher, does its thing, and
then returns true (if handled) like any other one. Do I need to do any
manual hibernate cleanup? I thought this was handled by a background
event but I'm at a bit of a loss...
thanks again for all the input
snoopy dance made me laugh :-D
Padawn wrote:
Since it's just my intuition speaking, I may be off-base, but...this sounds
like the beloved Hibernate Proxy and/or Cache issue, both of which
SnoopyDance all-over gray concurrency areas. Try substituting the query
code for a, literally, straight get(persistentClass, databaseId); call and
see if the issue is still there.
Bit of a performance it, but better to sweat that later.
