jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Rohead <SRoh...@webmiles.com>
Subject RE: Major design flaw in DBTags!
Date Tue, 19 Jun 2001 18:05:25 GMT
I'm confused.  The closeConnection tag will definately *not* be called in
the presence of exceptions under *any* version of the spec, so the solution
using release() is no worse under implementations of 1.1 that don't call
release in a finally block.  However, in 1.2, it is mandated by the spec to
be called in a finally block.  The spec states:



Once all invocations on the tag handler are completed, the release method is
invoked on it. Once a release method is invoked all properties, including
parent
and pageContext, are assumed to have been reset to an unspecified value. The
page compiler *guarantees* that release() will be invoked on the Tag handler
before
the handler is released to the GC. (jsp-1_2-pfd-spec, page 164, emphasis
added)



And also:



public void release ()

Called on a Tag handler to release state. The page compiler *guarantees*
that
JSP page implementation objects will invoke this method on *all* tag
handlers,
but there may be multiple invocations on doStartTag and doEndTag in
between. (jsp-1_2-pfd-spec, page 166, emphasis added)




TryCatchFinally is probably a more elegant way of doing it, but release() is
the best option for 1.1/1.2 compatability.  The only case it doesn't work is
those 1.1 containers that don't call release() in a finally block (many
containers do, even though the spec doesn't specifically *require* it),
which as I mentioned earlier is no worse than a separate closeConnection
tag, which will never be called in the presence of exceptions.

Sean Rohead


-----Original Message-----
From: Morgan Delagrange [mailto:morgand@apache.org]
Sent: Tuesday, June 19, 2001 11:27 AM
To: 'taglibs-dev@jakarta.apache.org'
Subject: RE: Major design flaw in DBTags!


Hmm, after looking at the spec, there are two problems with using the
release() method to clean up connections.  One, it's not guaranteed to be
called if the tag throws an exception.  Two, it's not guaranteed to be
called at the end of the page; it could be called after the last
doEndTag() method of connection.  Crap.

So it seems like the only way to insure that the connections are closed is
by using TryCatchFinally in a begin/end tag format, and it will only be
guaranteed in JSP 1.2; a JSP 1.1 container would never call the
method.  And if a nested connection failed, the enclosing connection would
probably still remain open.  Not very appealing.

Side issue: I would have to assume that containers will not reuse tag
instances that are nested.  I don't see how it could work otherwise.

- Morgan


On Tue, 19 Jun 2001, Morgan Delagrange wrote:

> Yeah you wouldn't need a second connection tag at all if they actually use
> the same connection, but that's not necessarily the case.  If they are
> using different connections, implicit collaboration is not possible.
> 
> I'm not trying to be obstinate.  :)  I just think the current design is
> friendlier and more backward compatibile.  I should be able to change the
> release() method to clean up connections without changing the interface,
> so we only need change the interface if it will make usage cleaner.  I'm
> not convinced that it does.  I like:
> 
>   <connection>
>     <url/>
>     <user_name/>
>     <password/>
>   </connection>
> 
>   <statement/>
> 
>   <!-- potentially optional in JSP 1.2 -->
>   <closeConnection/>
> 
> better than:
> 
>   <connection>
>     <!-- 
>       don't like how connection info is a sibiling 
>       of statement
>     -->
>     <url/>
>     <user_name/>
>     <password/>
>     <statement/>
>   </connection>
> 
> - Morgan
> 
> 
> On Tue, 19 Jun 2001, Shawn Bayern wrote:
> 
> > On Tue, 19 Jun 2001, Morgan Delagrange wrote:
> > 
> > > I still think this syntax is confusing.  What's going on inside of
nested
> > > loops?
> > > 
> > > <connection>
> > >   <url/>
> > >   <user_name/>
> > >   <password/>
> > >   <statement>
> > >     <resultset>
> > >       <connection>
> > >         <url/>
> > >         <user_name/>
> > >         <password/>
> > >         <statement>
> > >           <resultset/>
> > >         </statement>
> > >       </connection>
> > >     </resultset>
> > >   </statement>
> > > </connection>
> > > 
> > > Is a new connection being created for every row in the enclosing
> > > resultset?
> > 
> > Nested conditions could collaborate implicitly.  E.g.,
> > 
> >    <connection url="" user="" pass="">
> > 	<statement>
> > 	    <resultset>
> > 		<connection> <%-- no url specified, so use parent's --%>
> > 		   <statement>
> > 			<resultset />
> > 		   </statement>
> > 		</connection>
> > 	    </resultset>
> > 	</statement>
> >     </connection>
> > 
> > Shawn
> > 
> > 
> 
> 

Mime
View raw message