yes, that's right, that proxy will handle PER_THREAD scope
Hrg Davor On 10/29/07, Chris Lewis <[EMAIL PROTECTED]> wrote: > > 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" <users@tapestry.apache.org> > > > > > > An > > Tapestry users <users@tapestry.apache.org> > > 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] > >
