Hibernate is very flexible and heavy weight but I find the gains of its query interface all worth it.
The tough side with hibernate is that everything is configured by default on the very minimal settings. A solution for lazy loading is to enable cascade operations. This can spread the session through a graph of objects. Also with hibernate interceptors and the new Tapestry 4 engine interface, I believe there could be a "transparent" solution for managing the sessions: collect all the hibernate objects referenced in the session and reconnect them. Although, we have not used any persistent hibernate object... and I'm not sure to understand the rewind issue... wouldn't you clear a persistent property if it shouldn't be used anymore? On 8/31/05, Gentry, Michael (Contractor) <[EMAIL PROTECTED]> wrote: > Personally, I'd categorize Hibernate as "the most popular game in town" > and not "the best game in town". I've never had these kind of issues > with Cayenne or EOF in my web-based applications (perhaps other issues, > but nothing like these cross-request/response problems). I suspect > there are other persistence frameworks that also do not have these > issues in a web-based environment (I haven't gone looking -- Cayenne/EOF > work great for me). > > /dev/mrg > > > -----Original Message----- > From: Patrick Casey [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 31, 2005 12:43 AM > To: 'Tapestry users' > Subject: RE: Transaction handling. Where? > > > > > <snip> > > Anyway, I was just arguing with this statement: > > > > > I really think the whole "we refuse to automatically reconnect to > > > lazy-load a connection and instead insist on throwing and > > > exception" is database-purist-arrogance on the part of the > > > Hibernate team. Most of their library is great, but this behavior > > > is just *not* web friendly, and their smug assurance that it's "not > > > a big deal to workaround" turns out not to be true in practice. > > > > That's a little hard on Hibernate. Granted that they could provide > > more options, but ... working within the one-transaction-per-request > > model that you prefer, it is, in fact, not a big deal to work with -- > > with, not around. > > I am being a little hard on Hibernate, but I have to admit I'm > feeling that way right now as it really feels like a round peg in a > square > hole. From what I've done with it, it's a phenomenal tool as long as you > stay on the server, but as soon as you return a web page, many of the > assumptions that underly the Hibernate Architecture cease to make sense. > > Likewise, why *can't* Hibernate grab a new transient session to > avoid lazy initialization errors? There's no real functional reason > other > than the developer's desire to maintain "purity" and if you look at > their > explanations as to why they insist on this lazy model (at least in my > Hibernate in Action book), they're about design philosophy, not > practical > engineering problems. > > *** Speculation Alert > > It feels to me like the library was designed for more classic > client/server applications where the programmer had much more control > over > what was going on. That didn't turn out to be all that popular a use for > server side java, but web servlets did, for which Hibernate was *almost* > a > good fit (and the best game in town), so it became a web-server > persistence > layer. > > I could very well be wrong mind you, but a lot of the design > decisions and assumptions make perfect sense in a classic client/server > model, but just don't follow in a web model. The whole Lazy > Initialization > model, for example, wouldn't be a big deal in a classic model, but is > really > awkward in a web application. > > In any event, enough of a rant on my part; it's still the > persistence framework I'm using so I can't hate it *that* much as I > haven't > swapped it out for something else yet. > > --- Pat > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Henri. www.actualis.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
