Return-Path: Delivered-To: apmail-jakarta-taglibs-user-archive@jakarta.apache.org Received: (qmail 6193 invoked by uid 500); 3 May 2001 18:01:00 -0000 Mailing-List: contact taglibs-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: taglibs-user@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list taglibs-user@jakarta.apache.org Delivered-To: moderator for taglibs-user@jakarta.apache.org Received: (qmail 62680 invoked from network); 3 May 2001 16:02:25 -0000 Message-ID: <000501c0d3ea$97db17e0$86565f18@columbus.rr.com> From: "Brent Johnson" To: References: Subject: Re: JDBC Statement tag: connection scope Date: Thu, 3 May 2001 12:03:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N In the documentation under 'closing connections' it says "unless you're performing your own connection pooling, always close your connection." Well, I am performing my own pooling and I would like to set up two connections (to different DBs) at the beginning of a request, but I can't put them at REQUEST_SCOPE because the statement tags won't find them. A side note, the example in the documentation shows 'id' rather than 'conn' in the sql:closeConnection tag which is incorrect. ----- Original Message ----- From: "Morgan Delagrange" To: Sent: Wednesday, May 02, 2001 1:21 PM Subject: Re: JDBC Statement tag: connection scope > > > On Wed, 2 May 2001, Brent Johnson wrote: > > > The statement tag gets its connection as follows inside of doStartTag(): > > Connection conn = (Connection)pageContext.getAttribute(_connId); > > > > This means that the connection must be defined at PAGE_SCOPE. This seems a bit restrictive. What if my connection isn't at page scope? Is there a reason why the statement tag doesn't use pageContext.findAttribute()? > > The tags doesn't support assigning to another scope, so > that's the only real logic there. I suppose it could use findAttribute, > but I don't really dig on people storing Connections at other > scopes. That's what database pools are for. :) > > - Morgan > >