× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I would recommend going with J2EE standards here.  J2EE defines a standard 
for connection pooling.  In your code you use JNDI to get a dataSource 
object from which you can then obtain a connection.  Often, you will cache 
the actual dataSource itself so that you do not have to repeatedly run 
that code.

In your web application you define a resource reference for this 
datasource which is basically just a name you want to give it, this name 
is what you use in your code to lookup the data source.

When your application is installed in WebSphere or another J2EE server the 
person doing the install has to "bind" that resource reference with an 
actual connection pool that has been configured in the application server. 
 This technique puts a "wall" between your code and the actual runtime 
configuration of the connection pool.  It also gives the deployer 
flexibility in how they want to manage the pool.  For example, they could 
just define one master pool that they bind for all applications, or they 
could create specfic pools for each application.

In your code you shouldn't have to know or care about issues like what 
JDBC driver is used.  That information is configured when the connection 
pool is defined and is on the "other side of the wall" from your code. You 
just need to get and use a generic java.sql.DataSource object.

Mark




wdsci-l-bounces@xxxxxxxxxxxx wrote on 01/21/2004 09:50:30 AM:

> Hello,
> I'm researching best practice for iSeries EIS data access from a 
> Model 2 framework.  I believe it would behoove me to have a pool of 
> connections to my iSeries DB ready for web traffic, rather than 
> performing them for each request. I'm confused with all the 
> literature referencing DTO & DAO I am finding when reviewing the 
> RedBooks found via a connection factory search. 
> At my front controller Action Servlet init(), I thought I would 
> prepare a data base connection pool for latter use in the Servlets' 
> doGet/doPost method.  I planned to insert my specific code in 
> doGet/doPost to log stats about my form by HttpServletRequest.
> getParameter("session"), which I would be updating in subsequent 
> pages.  I'm hoping I can retrieve the session and use it as a key in
> my iSeries tracking file, any tips appreciated.  The forwarding 
> pages would be determined via ActionForward returned from my Action 
> class.  Any URL's or recommending reading would be appreciated.  I'm
> currently finding stuff like JCA, resource adaptors.  Is this the 
> location I should dig in with my research?
> It's certainly a fun course of discovery learning Java and the 
> different frameworks available.  In RPG, we rarely name our design 
> patterns, it sure helps when communicating ideas to have a common 
> syntax for these designs.  The more I play with the Java, the more I
> learn how much more I need to learn.  This keeps it fresh and exciting.
> Thanks to all for years of sharing of ideas and tips. 
> David Kelly 
> 
> _______________________________________________
> This is the Websphere Development Studio Client for iSeries  (WDSCI-
> L) mailing list
> To post a message email: WDSCI-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
> or email: WDSCI-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/wdsci-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.