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