<snip>
> P.S.: thanks again for the hibernate tip with keeping dao and session
> together :-)
I actually got a wee bit more sophisticated with this when I
realized that I could now support three different persistence methods via
the DAO. So now with my DAOs you can choose the persistence mechanism you
want (Detatch and Lock, Key and reload, or Persist Session) as a flag.
I found that by defaulting to key and reload and only using session
persistence for the cases where I actually needed it, I could really clamp
down on my session memory use but still have the session persistence
available when I needed it. Since all access to the object was encapsulated
inside the DAO, I could let the DAO worry about associating it with a viable
session (or fetching it if need be) on first use.
So if you're going down that road (and it sounds like you are), then
allowing multiple persistence models in your root DAO instance might (or
might not) help you get something of the best of both worlds.
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
