Thanks guys ... I'll take some time trying to wrap my head properly arround this and get back to you with questions or success stories .
It's starting to sound like shaky ground , and problems if i use the wrong aproach . So basically one approach coculd give me scalability issues in terms of mixing session data , and the other one is resource wastefull having to open and close a session for each request . ( alltough in my scenario that wouldn't be such a big issue ) . I've never used hibernate without spring , and this might confuse me as I am not well aware of what's going on with the Session object exactly . Cosmin On 12/18/05, Scott Russell <[EMAIL PROTECTED]> wrote: > On Mon 19 December 2005 12:56, Paul Cantrell wrote: > > This has come up on the Tapestry list before. A less radical and > > perhaps less convoluted solution -- if your application can handle a > > one-db-session-per-request model, which is not true for everyone -- > > is to open and close the Hibernate session using a servlet filter, > > keep the session on a ThreadLocal while it's open, and never keep > > persistent objects in the session (keep their keys instead). This is > > arguably best practice anyway: it prevents several insidious > > scalability and data consistency problems. > > > > If this sounds useful, let me know and I'll post my code. > > > > I would worry that Scott's solution is going to be wastefully > > reopening and closing Hibernate sessions, and maybe mixing data from > > different transactions in time in undesirable ways, but it is quite > > clever! > > > > Spring already supply a suitable filter that does this, > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter. My > solution still requires this filter to be present, as it only attaches > page-persistent objects back into an existing session on the current thread. > Otherwise, as you pointed out, it would be needlessly creating a new > hibernate session for each page property that was loaded up. > > But of course only storing object keys in the session is the leanest and most > scalable approach, if you don't mind hitting the database on every request. > > regards, > Scott > > > --------------------------------------------------------------------- > 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]
