× 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.


  • Subject: RE: Source Evaluation?
  • From: kulack@xxxxxxxxxx
  • Date: Fri, 9 Feb 2001 09:11:31 -0600

Can't speak a whole lot of specifics about Websphere except as it
relates to DB access so in a true distributed fashion,
I'll give my comments from that perspective while
others comment specifically on the servlet/html/webserver,
etc.

Also in reference to this post:
On 02/08/2001 at 05:24:58 PM, owner-java400-l@midrange.com wrote:
I am trying to use the WebSphere connection pool for database access. I
would
like someone elses opinion on connection pools (actual use).  You might
also try putting your try {  database connection  } catch block inside the
init() method after super.init(config) statement. init() is initilized one
time and you only need database connection one time.


Websphere or your own connection pool is something I'd consider a
must have in any real production level servlet that's going to scale
at all.

Websphere has really good connection pooling, and you'll also get the
added benefit of prepared statement pooling.

The prepared statement is a somewhat expensive resource too.
Websphere also handles timeout conditions on the connections
as you're using them (i.e. if your servlet hangs or goes into
a comatose state, websphere will eventually reclaim your connection
so that it can be used again).

Its got quite good support for using the connection pool settings
as a mechanism to throttle up or down your entire server.
Imagine having multiple servlet packages all managing their
own connections.
You really don't want that in an application server environment,
you want to abdicate that responsibility to the server.


If you don't use Websphere connection pooling (and you should),
storing the connection in the servlet itself is a good idea.

Couple of issues you need to be aware of then:
1) multi-threaded access. By default, servlets are multi-threaded,
meaning the server can invoke the doXxxx() method of ONE object
in as many threads at a time that it needs to.
2) You'll have to be sure you appropriately protect the
object level stuff. You could also implement the SingleThreadModel
in your servlet, but dunno if I'd recommend that.
3) You don't get any pooling of your prepared statements, you
want that.

On a seperate note:
In the getFileName.java, you wouldn't want to execute
select * just to get the name of the columns. That's perhaps
overkill depending on the driver and its row blocking, and
where on the network you are related to your database,
the executeQuery() may pull lots of data across the wire.
Your mileage may vary.
You could select the column names from the SQL system tables.
In JDBC 2.0, you wouldn't have to actually execute the query in
getFile(), but could use PreparedStatement.getMetaData().



"Do you believe that my being stronger or faster has anything
 to do with my muscles in this place?" ... "Free your mind."
Laurence Fishburne as Morpheus in 'The Matrix'.

Fred A. Kulack  -  AS/400e  Java and Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@bresnanlink.net
AOL Instant Messenger: Home:FKulack  Work:FKulackWrk


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.