|
Websphere provides an MBean that the customer can call to purge the connection pool of its connections. This will also, by definition, purge the preparedStatement cache as well. The StaleConnectionExceptions will not be thrown if this method is used. It also has the advantage of not removing the QSQSRVR(Native JDBC driver) or QZDASOINIT (Toolbox JDBC driver) prestart jobs from the system, so that the expensive process of starting more prestart jobs is avoided when the connection manager in WAS request more jdbc connections. StaleConnectionExceptions are still thrown in WAS 6.0 for connections that have gone 'stale' during operation, but since an application must catch SQLExceptions anyway, it does not have to explicitly monitor for StaleConnectionExceptions. WAS 6.0 also has a feature that allows the user to specify that connections be pretested on a defined interval to avoid StaleConnectionExceptions for connections handed out by the connection manager. Refer to the WAS 6.0 doc ( http://publib.boulder.ibm.com/infocenter/wsdoc400/index.jsp) and search for the phrase 'pretest connections'. Frances Stewart WebSphere Application Server for iSeries, Technical Team Lead/Architect External web site: http://www.iseries.ibm.com/websphere Team web site: http://w3.rchland.ibm.com/~was E-mail: francess@xxxxxxxxxx IBM Rochester NGay@xxxxxxxxxxxx m Sent by: To java400-l-bounces Java Programming on and around the @midrange.com iSeries / AS400 <java400-l@xxxxxxxxxxxx> cc 02/23/2006 09:18 AM Subject RE: WAS 5.1 Express Connection Pool -- Lives how long??? Please respond to Java Programming on and around the iSeries / AS400 <java400-l@midran ge.com> >> Furthermore, you should NEVER, >> NEVER "kill the server side jobs". > I know, but I was willing to accept those errors, each app has it's own > datasource so at least I'd only effect one of the apps, not all of them. Does your app detect & deal with StaleConnectionExceptions correctly? We *had* to write this in (we're on WAS 4.0), otherwise from time to time users would see these - so I created a special "getConnection" method that would first get the connection and then run a small test SQL query against a small table to prove whether or not the connection was stale. If it was fine, it would return the connection to the app to be used, if it was stale, it would throw away the connection and try looping up to 5 times to try to get a "good" connection. So with this in place I don't see what the big deal is with killing the server side jobs? Its not something we make a habit of but I've always viewed it as a safe thing to do if necessary, the only danger being that if one of the jobs was running a query that takes a while and you kill it in the middle of running the query then the user on the website waiting for that query would see an error. Also we're in the process of upgrading to WAS 6.0 - does this handle StaleConnectionExceptions itself or do we still need our custom code for dealing with this? If we do, then I can't find the JAR with the StaleConnectionException class it in anymore (at least not in WSAD 6.0... don't have actual WAS 6.0 installed on our iSeries yet). It used to be in cm.jar? Many thanks, Nigel Gay, Computer Patent Annuities. "Walden H. Leverich" <WaldenL@techsoft To inc.com> "Java Programming on and around the Sent by: iSeries / AS400" java400-l-bounces <java400-l@xxxxxxxxxxxx> @midrange.com cc Subject 23/02/2006 11:26 RE: WAS 5.1 Express Connection Pool -- Lives how long??? Please respond to Java Programming on and around the iSeries / AS400 <java400-l@midran ge.com> > The changes made to a datasource are not dynamic ..... >they need to stop and start the server to pick them up. Yuck! Net effect is that I have to bounce the server to add a library to the list? Yuck. Case in point, I needed to add a library to a data source yesterday for new functionality in _one_ of several applications on the server. I have to bounce all the apps on the server to add functionality to one? Yuck. >Furthermore, you should NEVER, >NEVER "kill the server side jobs". I know, but I was willing to accept those errors, each app has it's own datasource so at least I'd only effect one of the apps, not all of them. Does 6.0 have the same limitation? And what's the "best practices" then for deploying apps? One app server per datasource so if you need to mod a datasource you don't need to bounce all the unrelated apps? -Walden ------------ Walden H Leverich III Tech Software (516) 627-3800 x3051 WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -- This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/java400-l or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l. ******************************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorised. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. ******************************************************************************** -- This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/java400-l or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
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.
midrange.com
