Agreed that it might be possible to make the "transient session" idea
work very nicely, but I really think you're making a mountain of a
molehill. Hibernate has worked smoothly in the webapps I've done.
Cheers,
Paul
On Aug 30, 2005, at 11:43 PM, Patrick Casey wrote:
<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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
