cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 13:43:43 GMT
> From: Berin Loritsch []
> > From: Vadim Gritsenko []
> >
> > In J2EE, it is common to have session EJBs working with JDBC
> > connection. You obtain connection whenever you need it and
> > return to the pool when you are done.
> Semantic clarification:
> You get the DataSource, and call getConnection().  The DataSource
> may have pooled the connection or not.  That's not really the
> point.  You never explicitly return it to a pool.  You call
> connection.close(), and if the connection is pooled then it is
> silently returned to the pool.
> That is a key distinction.

Ok, I used wrong name here, replace JDBC Connection with
SomeLegacyLimitedResourceComponent for this discussion, limited in count
and critical for application, and thus must not be held for too long

> You LOOKUP the DataSource, which can be shared between all threads,
> and then you USE it to get the connection INSTANCE.  The instance
> is used the same way WHETHER IT IS POOLED OR NOT.

JDBC connection must be aware of pooling (special handling in the
close() method), which does not look good - current Avalon model where
poolable component must not care about how it is being pooled is *much*

> I am advocating the same thing for the CM

Do you propose to make pooling concern of the component? (I.e., manual
pooling as in JDBC?)


To unsubscribe, e-mail:
For additional commands, email:

View raw message