I am reading this thread and cannot understand what you, guys, are
talking about here. We are using session per transaction strategy (not
even per request) for a relatively large site (Spring + Hibernate). We
simply correctly initialize our domain objects through
Hibernate.initialize or plain HQL before passing them to Tapestry.
Long sessions? This is a scalability bottleck plus it completely
conflicts with J2EE transactions as long session are essentially long
transaction without DB support.
And in addition... I hope you understand that for every request where
you would have gotten lazy exceptions, now you will be making a DB query
(or hit the second level cache in the best case). For every call!!!
"Hibernate in Action" is a must-read here.
Wow.
Serge
Henri Dupre wrote:
On 9/23/05, Schulte Marcus <[EMAIL PROTECTED]> wrote:
We're using using long sessions in two productive apps now. It works great
and, for us, simplifies development considerably. Our first app using
hibernate used Spring w/ session per request and it generated some really
nasty ad-hoc work-around-code.
We've implemented the long-session Pattern as a Hivemind service-model which
was really easy to do.
Did you have any troubles with sessions being serialized with a large
graph of objects?
Or did you find a workaround?
Thanks,
Henri.
---------------------------------------------------------------------
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]
