it is a proxy that implements the org.hibernate.Session interface :)
Chris Lewis <[EMAIL PROTECTED]>
29.10.2007 13:37
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
Re: Antwort: T5: 'wrapping' hibernate DAOs as services
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]
>>
>>
>>
>
>
