On Mon, Feb 27, 2012 at 3:55 PM, Ferran Maylinch <ferranmayli...@gmail.com> wrote: > This is surely a newbie question. > Before posting here I tried (with no luck) to find information about how to > use Session and/or HibernateSessionSource in my DAO's. > We are currently using both approaches but we don't know exactly when to > use each one. > When should we inject a HibernateSessionSource into the DAO and create > Sessions with source.create() and when should we directly inject a Session?
The basic rule is a session per thread. So, if you intend your database operations to be blocking and complete within the lifetime of the request, you can by all means inject the session. Note that either a session is created for you or you'll get a reference to the existing session when you inject a session. > In our application we have some DAOs calling other DAOs. What should I > inject to them: a HibernateSessionSource or a Session? Or should I pass a > Session to the DAO methods? Or DAOs calling other DAOs is discouraged? Usually inject the session everywhere, *except* if you your DAO needs to handle multiple simultaneous sessions. > And a further question would be: what happens if a class starts several > threads using Sessions and transactions. How should we handle that? > Sometimes we suffer deadlocks but we can't spot the cause. I see Howard managed to reply quicker... anyway, to add to his answer: although perhaps rare, there's definitely a use case for using HibernateSessionSource directly in case you explicitly want to use more than one session simultaneously. When you inject, you get the same session that will be closed at the end of the request (if the thread is within request context). Injecting a session also works fine for periodic jobs outside the request context. It's only when you want the session to extend its lifetime past the expected session close when you need to think through creating the sessions yourself. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
