Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 22859 invoked by uid 500); 7 Jun 2002 13:32:56 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 22848 invoked from network); 7 Jun 2002 13:32:55 -0000 Reply-To: From: "Berin Loritsch" To: Subject: RE: [Design] ContainerManager is under fire--let's find the best resolution Date: Fri, 7 Jun 2002 09:32:38 -0400 Message-ID: <002801c20e27$cabc32c0$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <00a401c20db6$7f8b26b0$0a00a8c0@vgritsenkopc> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > 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. 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. I am advocating the same thing for the CM --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org