Brian Lough wrote: > 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). This is occurring in a development environment on a fresh and small app with a schema with a total of 6 mapped entities, 7 tables, 3 records in the abstract entity's table, one user (me), and all queries working completely normally in the context of pages. I can't say it's impossible for this to be a data issue, but the odds of that are miniscule. > 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? As it turns out it doesn't make sense for what I'm writing (a binary file dispatcher), but when I ran into this I was struck with a bolt of "I must understand this." A realistic use however is access control, in which you want to restrict T5-specific idioms like a "page" or "component." > > > 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. >>> >> >> >
-- http://thegodcode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
