jtravis_hyperic
Hot Shot
Hot Shot

Storing DAOs in session beans

I just noticed something that I've been doing lately: storing a
reference to a DAO in a session bean so that I don't have to keep
fetching it.

The problem with this is that the current Hibernate Session is stored
with that object which is fine to do, but the way I'm using it is
totally broken.

So, I have a couple ideas of what we can do about this & wanted to
run it by people:

1 - Allow people to store the DAO in their variables, not having to
re-create them. We solve the Session problem by storing the current
session in ThreadLocal somewhere. This way people can re-use their
DAOs and they will automatically pick up the right session.

2 - Tell people to not hang onto their DAOs. The problem here is
that someone _could_ hang onto it & end up with strange bugs because
of it.

I'd vote for #1, since it makes it hard for the programmer to do the
wrong thing.

-- Jon


0 Kudos
1 Reply
jtravis_hyperic
Hot Shot
Hot Shot

I've implemented #1. Basically we no longer store the session in any
class. We simply ask the sessionfactory for it each time. This is
the correct thing to do, since Hibernate actually has its own plugin
infrastructure (CurrentSessionContext) to store and locate the
current session.

As a detail, I've also removed all the Mock DAO factory code.

We could actually simplify even more and remove the interface for the
DAOFactory, and just have a single class.

-- Jon


On Nov 14, 2006, at 1:28 PM, Jon Travis wrote:

> I just noticed something that I've been doing lately: storing a
> reference to a DAO in a session bean so that I don't have to keep
> fetching it.
>
> The problem with this is that the current Hibernate Session is
> stored with that object which is fine to do, but the way I'm using
> it is totally broken.
>
> So, I have a couple ideas of what we can do about this & wanted to
> run it by people:
>
> 1 - Allow people to store the DAO in their variables, not having to
> re-create them. We solve the Session problem by storing the
> current session in ThreadLocal somewhere. This way people can re-
> use their DAOs and they will automatically pick up the right session.
>
> 2 - Tell people to not hang onto their DAOs. The problem here is
> that someone _could_ hang onto it & end up with strange bugs
> because of it.
>
> I'd vote for #1, since it makes it hard for the programmer to do
> the wrong thing.
>
> -- Jon
>


0 Kudos