Re: [SOT] SingleThreaded components vs. Singletons
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. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [SOT] SingleThreaded components vs. Singletons
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 :-) -- Reinhard
Re: [SOT] SingleThreaded components vs. Singletons
Il giorno 12/dic/04, alle 08:38, Reinhard Poetz ha scritto: 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? I think you mean ThreadSafe instead of SingleThreaded. A single-threaded component won't usually be a singleton, unless you want to severely compromise the scalability of your app. Single-threaded components are typically instantiated per-request or are pooled. Thread-safe components can be used safely by many threads at once and as such can be singletons. The Hibernate SessionFactory object is meant to be a singleton and you could wrap it inside an Avalon ThreadSafe component in order to have it managed by the Excalibur component manager inside Cocoon. HTH, Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [SOT] SingleThreaded components vs. Singletons
Ugo Cei wrote: Il giorno 12/dic/04, alle 08:38, Reinhard Poetz ha scritto: 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? I think you mean ThreadSafe instead of SingleThreaded. yep :-/ A single-threaded component won't usually be a singleton, unless you want to severely compromise the scalability of your app. Single-threaded components are typically instantiated per-request or are pooled. Thread-safe components can be used safely by many threads at once and as such can be singletons. The Hibernate SessionFactory object is meant to be a singleton and you could wrap it inside an Avalon ThreadSafe component in order to have it managed by the Excalibur component manager inside Cocoon. As advantages I can think of putting the confiuguration of the component into cocoon.xconf and I only have to choose the right interface. Are there other advantages of having the ECM manage the component? -- Reinhard
Re: [SOT] SingleThreaded components vs. Singletons
Il giorno 12/dic/04, alle 14:24, Reinhard Poetz ha scritto: As advantages I can think of putting the confiuguration of the component into cocoon.xconf and I only have to choose the right interface. Are there other advantages of having the ECM manage the component? Not that I know of. Personally, I used to manage the SessionFactory myself, without using Avalon. Until I switched to using Spring, that is :-) Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
[SOT] SingleThreaded components vs. Singletons
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? -- Reinhard
