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 :-)
-- Reinhard
