From cocoon-dev-return-11845-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org Fri Mar 16 15:40:31 2001 Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 26797 invoked by uid 500); 16 Mar 2001 15:40:17 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 26699 invoked from network); 16 Mar 2001 15:40:08 -0000 Message-ID: <3AB2332D.39E313A6@apache.org> Date: Fri, 16 Mar 2001 10:37:17 -0500 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [PATCH] Re: [C2][Xalan2] Xalan2J problems under heavy load using Apache JMeter References: <3AB13C03.1080603@hisitech.com> <3AB13D19.29CC1357@apache.org> <3AB159E2.4080601@hisitech.com> <3AB1969B.C21E1D6C@apache.org> <3AB1FD75.5000508@hisitech.com> <3AB21A47.5DF8BFAC@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Berin Loritsch wrote: > > Santiago Gala wrote: > > > > Berin Loritsch wrote: > > > > I would reimplement it completely, locking the whole set of operations. > > A good way to start is to change public methods init(), get(), put(), > > dispose() to synchronized methods and wrapping the while in run() in a > > synchronized( this ). I made some extensive changes to the JdbcDataSourcePool code, using the Avalon Lock implementation (and I corrected a synchronization error there). I changed the Thread that monitored the class to simply create the full number of datasources. It does it asynchronously, so that the pool acts like a "Future" object. When the pool is fully populated, it marks itself m_initialized = true. When someone tries to get() and the object has not been initialized the pool checks to see if the asynchronous initialization is done. If the thread has not been created we throw an IllegalStateException, otherwise we wait for the thread to finish. We also check to see if the pool is disposed. If not, then we procede to get an object. Since we are not dealing with the possibility of growing the pool, the get() code is simplified a bit. When someone tries to put() an object, the code checks to see if the pool has been initialized--if not, it throws an IllegalStateException (How can we receive an object if it never was created?). It then checks to see if the pool has been disposed. If it has, it destroys the JdbcConnection, otherwise it returns it to the pool. Hopefully this will satisfy most of the race conditions. --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org