hi! I think the generic data access objects on the hibernate page could be usefull as they, among other things, support a generic way to specify the id (not only long).
One thing that I come to think about regarding the session-per-conversation pattern is that there could be memory issues. the session cache could grow (per session!), and that would not scale very well. I`m quite new to hibernate and peristent layers in general so I could be wrong here :) I haven`t seen the stuff Jesse has done, where can I find it? On 1/17/06, Schulte Marcus <[EMAIL PROTECTED]> wrote: > hi ted, > thanks for the feedback! > > > Why do you not use Hivetranse for session/transaction management? > > There has already been done alot of work on that. It is a clean > > Hivemind contribution. Check it out! > > http://hivetranse.sourceforge.net/ > > > That's a story which went a bit "unlucky". Last summer, I had a look at > hivetranse, but it didn't support hivemind 1.1 yet which I already used, and > I really didn't want to backport ;). Then, I'm quite fond of the > session-per-conversation pattern which is still not supported by hivetranse. > It seems to be scheduled for hivetranse 0.6, however. Lastly, I didn't have > the time to dig into hivetranse deeply enough to add what I needed. > > > Also, as you are using Java 5.0, I think you should consider using the > > following patterns for generic data access objects: > > http://www.hibernate.org/328.html > > > That would mean a generic AbstractPersistenceService, ... yes, looks like it > would make sense... > > > Another thing is the HibernateSqueezer on the wiki. I think it is > > really a good thing, and easy to implement thanks to Hivemind. > > http://wiki.apache.org/jakarta-tapestry/HibernateTapestrySquee > zer?highlight=%28hibernate%29 > > That's definitively on my list for the next release. I'd like to have > session-per-request, no detached objects as the second supported pattern > (besides session-per-conversation). As far as i can see, that'll need a > Datasqueezer and a custom PropertyPersistenceStrategy I'll take the > Wiki-thing as a starting point. Also, Jesse uses this approach while I do > not (currently), so I hope I'll be able to take a lot from his code. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- /ted --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
