Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 23047 invoked from network); 23 Feb 2000 01:32:07 -0000 Received: from unknown (HELO web1.epitonic.com) (216.33.145.58) by locus.apache.org with SMTP; 23 Feb 2000 01:32:07 -0000 Received: from bmovie (host-216-34-131-222.exodus.net [216.34.131.222] (may be forged)) by web1.epitonic.com (8.8.8+Sun/8.8.8) with ESMTP id RAA18325 for ; Tue, 22 Feb 2000 17:29:29 -0800 (PST) Message-Id: <4.2.0.58.20000222172746.00d3c100@pop.epitonic.com> X-Sender: alex@pop.epitonic.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 22 Feb 2000 17:39:45 -0800 To: tomcat-dev@jakarta.apache.org From: Alex Cruikshank Subject: Re: [PATCH]: significant performance boost for JSP pages In-Reply-To: <38B32A98.AFAB0ECD@gefionsoftware.com> References: <4.2.0.58.20000222121423.00d3d960@pop.epitonic.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_530853957==_.ALT" --=====================_530853957==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:32 PM 2/22/00 -0800, you wrote: >Alex Cruikshank wrote: > > [snipped description of JSP performance problems] > > What's worse, the code called from a synchronized method, > JspLoader.loadJSP(), > > which means that every JSP page request will have wait its turn to execute > > this code. [...] > >I'm pretty sure this method was made synchronized as a quick and dirty fix >for a serious multithreading problem (two JSP pages accessed for the first >time >at roughly the same time ended up as servlets mixing content from the two >pages). Besides removing "synchronized", the core problem must be solved. I don't advocate removing the synchronization, but rather, increasing the granularity of the synchronization block. + if ((jspClass == null) || (compiler.isOutDated() )) + { + synchronized ( this ) + { + if ((jspClass == null) || (compiler.isOutDated() )) + outDated = compiler.compile(); + } + } This type of construct is impossible without making the isOutDated() method public. The code should be equally thread safe, because the file is tested before and after the synchronization lock. Synchronization can be expensive by itself, and I feel some effort should be made to avoid it where safe to do so regardless of the duration of the code within the synchronization block. - alex >Hans >-- >Hans Bergsten hans@gefionsoftware.com >Gefion Software http://www.gefionsoftware.com > >--------------------------------------------------------------------- >To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org --=====================_530853957==_.ALT--