cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
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 [mailto:bloritsch@apache.org]
> 
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> >
> > 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
time.


> 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*
better.

 
> 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?)

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message