cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [SOT] SingleThreaded components vs. Singletons
Date Sun, 12 Dec 2004 11:09:49 GMT
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>> For a quick hack I wrote a singleton (simple Java class) that manages 
>> the Hibernate SessionFactory. As it is only a Cocoon/Hibernate-demo I 
>> haven't thought much about it, but if I use Hibernate in production, I 
>> would write a SingleThreaded Avalon component. I would do it because 
>> Cocoon is based on Avalon, but are there any technical reasons?
> This is not an answer for your question but I recommend you do not use 
> Hibernate in Cocoon directly. For all database applications I use 
> following trio: Cocoon + Spring + Hibernate.
> Using spring as your "hibernate manager" gives you following advantages:
> - spring manages hibernate session in a transparent way
> - supports open session in view pattern
> - you can use declarative transaction management
> - supports DAO pattern (HibernateDaoSupport class)
> - if for some reasons Hibernate can't handle something (or is not that 
> performant as you'd wish it to) you can create a dao that uses jdbc. The 
> trick is that although jdbc dao gets the connection from datasource in 
> fact spring will pass the same connection that was used for hibernate 
> interaction. Reused connection means you keep everything in a single 
> transaction!
> - the code gets much shorter and cleaner as the exceptions are manager 
> by spring itself and coverted to runtime exceptions.
> - testing your hibernate DAOs/services will be a lot easier.
> just my 2c.

Thank you very much! I understand all those advantages. However using Spring 
introduces another layer of complexity. It's always a question of *who* is 
developing the application. The target group of the demo, that I was speaking 
of, has very little experience with web development and *never* used Cocoon at 
all. I'm going to focus on introducing the concepts of pipelines and flow, 
Spring would be too much ATM. At least I will prepare one silde giving an 
outlook on what could be improved in the future :-)


View raw message