right! so your daos can have singleton scope although they have a session reference!!!
you can look at the HibernateModule source. there is a very useful comment that explains how and why it works g, kris Chris Lewis <[EMAIL PROTECTED]> 29.10.2007 13:23 Bitte antworten an "Tapestry users" <[email protected]> An Tapestry users <[email protected]> Kopie Thema Re: Antwort: T5: 'wrapping' hibernate DAOs as services Kris, My DAOs are ignorant of Tapestry - I have no @Inject annotations in them. Instead they receive the Session object in the constructor, so technically they do have state. This is why I thought I might need to configure them as per-thread. However it sounds like you are saying that the Session that gets passed to my DAO constructor is actually a proxy to the actual hibernate session, and that this proxy takes care of getting a valid session. Is that right? Thanks :) Chris Kristian Marinkovic wrote: > hi chris, > > i did this too :) > > it is not necessary to make your DAOs have per-thread > scope (as long as they dont have a state!... they souldn't anyway). > All you have to do is to inject the session. tapestry-hibernate > generates a session proxy object that will obtain the actual > session from a per-tread HibernateSessionManager. > > g, > kris > > > > > Chris Lewis <[EMAIL PROTECTED]> > 29.10.2007 08:37 > Bitte antworten an > "Tapestry users" <[email protected]> > > > An > Tapestry users <[email protected]> > Kopie > > Thema > T5: 'wrapping' hibernate DAOs as services > > > > > > > Hello all, > > I'm building out the persistence infrastructure of my T5 app and would > like some opinions on accessing my DAOs. > > Summary: > I have DAOs for accessing my entities that provide common functionality > as well as prevent my higher-level web-app parts (pages/components) from > knowing about my persistence layer. That is, I won't be @Inject-ing > org.hibernate.Session instances, which while easy, would instantly tie > me to hibernate. Instead I'll be injecting my DAOs - or at least > top-level interfaces implemented by them (UserDAO, etc). > > Now what I have to deal with is accessing my DAOs from my > pages/components. It seems to me that 'wrapping' them as per-thread > services would make this extremely easy. In reality I'm not actually > wrapping the DAOs - I'm simply binding them and tagging them as > per-thread. Each implementation takes an org.hibernate.Session in its > constructor, which if I understand correctly, Tapestry IoC supports > transparently (constructor type args that is). > > What I end up with are DAOs that are ignorant of their role (as far as > their existence in Tapestry), and can be obtained by plain old Tapestry > IoC injection. The DAOs are thus created per-thread, but this seems > fairly logical to me as they should be cheap objects. They do hold > instance references to the Session, but as long as the DAOs are > per-thread this shouldn't present a problem. > > Does this seem like a sane path or am I overlooking something major? > > Thanks for the input! > > Sincerely, > Chris > > --------------------------------------------------------------------- > 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]
