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