session is just interface,
the instance you get is a proxy,
which redirects each method call to
the instance in current thread.
Davor Hrg
On 10/29/07, Chris Lewis <[EMAIL PROTECTED]> wrote:
>
> Sorry, this just sounds to magical. My DAO explicitly takes a Session -
> org.hibernate.Session - and holds that reference for its entire life.
> Basic code:
>
> import org.hibernate.Session;
>
> public class UserDAOImpl implements UserDAO {
>
> private Session session;
>
> public UserDAOHibernate(Session session) {
> this.session = session;
> }
>
> //....
>
> }
>
> How can this session, which is declared as (and passed in as) an
> org.hibernate.Session, be 'fresh' after multiple requests?
>
> Davor Hrg wrote:
> > 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]
> >>
> >>
> >>
> >
> >
>
>
