Yeah I read that same section of the spec, but I didn't interpret it that
way. But in retrospect, I think you're probably right. It doesn't
specifically state that release() is still invoked upon an abnormal
termination, but that's probably what they're implying by talking about
releasing it to the garbage collector.
Well, let me think about it for a while. I still think the current syntax
is better, but it may be worth it in order to guarantee that the
connections are closed. I wish there was a method that was called at the
end of the page; that way, the interface wouldn't need to be changed.
- Morgan
On Tue, 19 Jun 2001, Sean Rohead wrote:
> 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:[EMAIL PROTECTED]]
> Sent: Tuesday, June 19, 2001 11:27 AM
> To: '[EMAIL PROTECTED]'
> 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
> > >
> > >
> >
> >
>
