Good idea. Adding support for CachedRowSet is on my to-do list
anyway. :)
On Tue, 19 Jun 2001, Glenn Nielsen wrote:
> An approach that can address this problem for JSP1.1 containers is to
> provide the ability in DBTags to use the CachedRowSet. CachedRowSet
> itself manages a connection to the db, opening it as needed. Taking
> the logic for managing the connection out of the JSP page.
>
>
>http://developer.java.sun.com/developer/technicalArticles/javaserverpages/cachedrowset/
>
> Regards,
>
> Glenn
>
> Shawn Bayern wrote:
> >
> > My two cents:
> >
> > I think an approach that involves tag containment in some way, whether
> > through Hans's approach or a similar one, will ultimately improve
> > maintainability (and might be necessary for coherent management of
> > short-term state). The more 'imperative' style of stringing building-
> > blocks together as unrelated tags (which communicate over scripting
> > variables or through the PageContext) might be more intuitive for some
> > page authors, but it leads to state-management problems.
> >
> > release(), as defined in JSP 1.2 (as of PFD2), isn't appropriate for
> > managing this kind of short-term state. The same handler might be reused
> > multiple times, and release() might be called until much later than many
> > tag-handler developers expect.
> >
> > Tag containment also allows for richer communication among active tag
> > handlers -- which can be good or bad, but it's arguably more powerful --
> > than the 'imperative' approach (i.e., peer, unassociated tags), which
> > depends on scripting variables or "scoped" attributes.
> >
> > In cases like this, which involve open/close-style resource allocation,
> > why not let the tags take care of state management instead of making the
> > operation explicit? For operations that need to come in pairs, the
> > typical recommendation is "make sure that the corresponding operations
> > occur at the same level of abstraction in code" (e.g., don't malloc() deep
> > inside a library call and free() at a higher level). If this syntactic
> > model ensures that this recommendation is followed, why is it a bad thing?
> > I don't think one syntax is clearly more intuitive than another, but one
> > seems to let the environment take care of operations automatically.
> > (This seems to be the primary intent of TryCatchFinally to begin with.)
> >
> > If the goal is to target JSP 1.1, it's a crap-shoot. For 1.2, the API
> > seems to provide a good solution.
> >
> > Shawn
> >
> > On Tue, 19 Jun 2001, Hans Bergsten wrote:
> >
> > > Sorry for jumping in here without having really looked at the DBTags, but
> > > I just thought I could offer what I believe is a different point of view
> > > on how to deal with connections.
> > >
> > > In the DB tags I developed for my JSP book, the tags that execute SQL
> > > get a connection from a JDBC DataSource (that implements a connection
> > > pool) available in the application scope, use it, and calls close()
> > > (thereby returning it to the pool), all in the doEndTag() method (in the
> > > default case). The DataSource is ideally placed in the application scope
> > > by a servlet that's loaded at startup, but for a pure JSP application,
> > > there's a useDataSource tag that can be used instead:
> > >
> > > <ora:useDataSource id="example"
> > > className="sun.jdbc.odbc.JdbcOdbcDriver"
> > > url="jdbc:odbc:example"
> > > />
> > >
> > > <ora:sqlUpdate>
> > > UPDATE Account SET Balance = Balance - 1000
> > > WHERE AccountNumber = 1234
> > > </ora:sqlUpdate>
> > >
> > > If multiple SQL statements must be executed through the same connection,
> > > i.e. forming a transaction, a special transaction element is used
> > > to enclose multiple DB tags. In this case the transaction tag gets
> > > the connection from the DataSource and the nested DB tags get the
> > > connection from the transaction tag. In this case they do *not* close
> > > the connection; it's closed by the transaction's doEndTag() instead.
> > >
> > > <ora:sqlTransaction dataSource="example">
> > > <ora:sqlUpdate>
> > > UPDATE Account SET Balance = Balance - 1000
> > > WHERE AccountNumber = 1234
> > > </ora:sqlUpdate>
> > > <ora:sqlUpdate>
> > > UPDATE Account SET Balance = Balance + 1000
> > > WHERE AccountNumber = 5678
> > > </ora:sqlUpdate>
> > > </ora:sqlTransaction>
> > >
> > > The DB tags catch exceptions to make sure the connection is always
> > > closed. When a DB tag is nested within a transaction, it rollbacks the
> > > transaction and close the connection in case of an exception, and then
> > > rethrows the exception.
> > >
> > > This approach seems to work in most cases, but it's not immune
> > > to exceptions thrown by scripting code within the body. For
> > > that, the JSP 1.2 TryCatchFinally is needed.
> > >
> > > If you believe you can pick up some ideas from my design, feel free
> > > to do so. All source code is available as part of the examples
> > > bundle at <http://TheJSPBook.com/>
> > >
> > > Hans
> > >
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
