Return-Path: Delivered-To: apmail-incubator-ibatis-user-java-archive@www.apache.org Received: (qmail 9567 invoked from network); 16 Mar 2005 09:13:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Mar 2005 09:13:19 -0000 Received: (qmail 24064 invoked by uid 500); 16 Mar 2005 09:13:19 -0000 Delivered-To: apmail-incubator-ibatis-user-java-archive@incubator.apache.org Received: (qmail 23856 invoked by uid 500); 16 Mar 2005 09:13:18 -0000 Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Precedence: bulk Reply-To: ibatis-user-java@incubator.apache.org List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 23841 invoked by uid 99); 16 Mar 2005 09:13:18 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from web50704.mail.yahoo.com (HELO web50704.mail.yahoo.com) (206.190.38.102) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 16 Mar 2005 01:13:17 -0800 Received: (qmail 13053 invoked by uid 60001); 16 Mar 2005 09:13:13 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=CEUyw+BzR+PwBE0w6oC3o3axflrDLyOw4nXCzwYvIcXWou8chL+NaM7rHC7C4e6PR05RJuZEg2Xzz9ypc7+z7uxgEN3M8/z/3S5Y6qW4lIv/VwhvhaHisgfc1Jl9qNywV7uqu4GpLgzAprCYQC0SxakiDJw12QHzJu2loeknvQw= ; Message-ID: <20050316091311.13047.qmail@web50704.mail.yahoo.com> Received: from [69.179.34.79] by web50704.mail.yahoo.com via HTTP; Wed, 16 Mar 2005 01:13:11 PST Date: Wed, 16 Mar 2005 01:13:11 -0800 (PST) From: Brett Gorres Reply-To: bgorres@yahoo.com Subject: RE: Oracle + iBATIS: more details To: ibatis-user-java@incubator.apache.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi Brian: Lest you place too much faith in Rahul's casual reply from earlier... You may be running out of available Oracle db connections or something like that. Your app design may be tying up too many connections. (Possibly even inside a loop in your code or something. That is optional.) Could be many things. Please don't take it the wrong way, but this is mostly in reply to Rahul who seems to be blaming Tomcat. I know I will appear as a stick-in-the-mud, but I'd rather suspect your Struts app's code / config before blaming products external to your project/organization. It's good to have a "guilty until proven innocent" approach to all new software. Your app is the newest kid on the block here. It will have bugs. Better to look into this before switching app servers without just cause! (I didn't see anything in your posts strongly suggesting anyone else's server/code as the culprit but I'll grant Rahul--anything's possible and I'm sure he knows something I don't.) My first assumption Brian is that you're dealing with a design flaw or bug in the Struts app or maybe using many calls to a query from within one service method--could be something like that in there. It depends on the styleof whoever wrote the app. One false move in a highly trafficked line of code can eventually slow down and crash (maybe sooner, maybe later) under ANY app server or ANY RDBMS. Just give it time. : ) Is it running out of memory or connections? Neither? You may need assistance on site to help determine that. This is all hypotyhetical. You may know all this. If you think the app may be poorly written, try to secure some time to simply clean it up! Do unit tests. If nothing else works: [make a good backup, and...] One good day of brave refactoring may be the only real prescription for finding and resolving your issue. You may know this. It probably never hurts to be reminded of it though. Deployment specifics of the app may be to blame. It could simply be [mis]configured for the Oracle server and not the SQL Server. Here is something to definitely check: I'd see if the number of db connections and the amount of RAM are equally available to the app in both database/hardware environments. Even if you do have, say, roughly the same configs for your different servers, you'll still be comparing apples with oranges... And here is another key issue: Ensure that db transactions are managed safely (if they must be managed by you at all) and that the app's memory usage is none too wasteful. I would just encourage people to keep these types of things in mind and "look in the mirror", before "pointing fingers" at other developers. Switching to different product(s) may only disguise your real issues until the true oversight [inevitably] comes to the surface--at a more inopportune time! Hope something in here helps somneone! Regards, -Brett --- Rahul Singh wrote: > Have you tried a slightly different app server like > Jboss or weblogic express? > > Rahul > > > On Tue, 15 Mar 2005 15:35:54 -0700, Brian Barnett > wrote: > > (Sorry if this double posts. Having problems with > other email account.) > > Hello, > > Hoping someone can give us some suggestions on how > to fix a problem we are > > facing. We have a Struts web app that runs against > both MS SQL Server and > > Oracle. MS SQL Server runs fine. When we run it > against Oracle, the > > performance slowly degrades until the web app > basically stops functioning. > > When we restart Tomcat, everything works fine > again for awhile. > > > > We are not sure if there are any specific steps to > duplicate, as our beta > > testers just "use the app" and then begin to see > the problem. > > > > Does anyone have any suggestions on how we can > troubleshoot this? > > > > Tomcat 5.0.28 > > iBATIS 2.0 build 274 > > Oracle 9.2.0.x > > Oracle Thin driver (ojdbc14.jar) > > > > TIA, > > Brian Barnett > > > > >