You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/12/12 08:38:56 UTC
[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
Re: [SOT] SingleThreaded components vs. Singletons
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 lgawron@mobilebox.pl
Project Manager MobileBox 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
Posted by Ugo Cei <ug...@apache.org>.
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/
Re: [SOT] SingleThreaded components vs. Singletons
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Ugo Cei <ug...@apache.org>.
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/
RE: [SOT] SingleThreaded components vs. Singletons
Posted by Adam Ratcliffe <ad...@mrigitech.com>.
I'm using the turbine-fulcrum security library
http://jakarta.apache.org/turbine/fulcrum/fulcrum-security-site/index.html,
this makes uses of an Avalon Hibernate wrapper. I'm not sure if this
component is actively maintained any longer as it has been deleted from the
HibernateExt repository, however maven will download it when you build the
security library.
Cheers
Adam
-----Original Message-----
From: Reinhard Poetz [mailto:reinhard@apache.org]
Sent: Sunday, 12 December 2004 8:39 p.m.
To: dev@cocoon.apache.org
Subject: [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