Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 89975 invoked from network); 18 Sep 2002 20:11:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Sep 2002 20:11:44 -0000 Received: (qmail 24233 invoked by uid 97); 18 Sep 2002 20:11:58 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 24202 invoked by uid 97); 18 Sep 2002 20:11:57 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 24190 invoked by uid 98); 18 Sep 2002 20:11:56 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) From: "neal" To: "Tomcat Users List" Subject: RE: Caching / Cloning Date: Wed, 18 Sep 2002 13:10:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3D88D48A.3050200@latte.harvard.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaaaah! Very interesting. You know I read a little excerpt from the Orielly book "Java and XsLT" last night at BOrders and it seemed to suggest a very similar strategy. Sounds like the Template is the key! I'm going to look more into this. Thanks for the tip! Neal -----Original Message----- From: Mark R. Diggory [mailto:mdiggory@latte.harvard.edu] Sent: Wednesday, September 18, 2002 12:31 PM To: Tomcat Users List Subject: Re: Caching / Cloning Actually, here's what I do: I have a Singleton Hashtable "Cache" class that I wrote, it holds the Templates, not the Transformers. In such a case you can get a transformer from the template instance in the cache without needing to read the xsl file again. When you don't find the template in the cache then you can stick a new instance in. -M. Mark R. Diggory wrote: > Put it in the "ServletContext", then its available to all Sessions and > Servlets across the application. > > Are jaxp Transformers syncronized at all? If so, couldn't different > sessions grab the same transformer from the context and use it? > > -M. > > neal wrote: > >> Actually, >> >> Isn't the SessionContext analogous to the session object in JSP? If I >> were >> to place the Transfomer object in their for cache it would be tied to a >> specific user and I would have to hold numerous copies of it >> simultaneouly >> whether they were in use or not. Seems like this would eat up a lot of >> resources. >> >> As for what I am currently trying to do ... I just created a single >> Hashtable which should be available to the entire application (all >> servlets) >> and it contains the Transformer objects for each XSLT. My plan was >> to have >> the servlet make a copy of one of these Transformer objects as needed >> and >> perform a >> transform and then destroy the copy, while the original would stay in >> cache >> in the Hashtable. I thought this way I could reduce the overhead of >> having >> to (a) read from disk and (b) parse the file into a DOM-like >> structure each >> time. >> >> It does not appear however that I can make a copy of a Transformer >> object >> however since it does not appear to implement the Cloneable >> interface. Is >> it just me or is this a significant limitation of Java ... that you >> can't >> make byVal copies of objects at will? SO frustrating!!! >> >> Can anyone make a suggestion for caching my XSLTs? >> >> Thanks. >> Neal >> >> >> -----Original Message----- >> From: Shannon Lal [mailto:slal_dev@hotmail.com] >> Sent: Wednesday, September 18, 2002 6:34 AM >> To: tomcat-user@jakarta.apache.org >> Subject: RE: Caching / Cloning >> >> >> Neal, >> Have you thought about using SessionContext. I believe the session >> context >> is specific to the session of the servlet, so when the instance of the >> servlet is run, it will have it s own copy of its Transforms to work >> with. >> That way you don t have to worry about different servlet instances >> locking >> of data. >> >> OR >> Are is the Transforms hashtable shared by all servlet instances. If so >> e-mail with more information about what you are doing and I can give you >> some more information. >> >> Nin >> >> >> >> >>> From: "neal" >>> Reply-To: "Tomcat Users List" >>> To: "Tomcat Users List" >>> Subject: RE: Caching / Cloning >>> Date: Tue, 17 Sep 2002 22:35:55 -0700 >>> >>> Siddarth, >>> >>> Thanks but I'm thinking of two possible issues: >>> >>> 1. using the ServletContext.getContext() - won't this still just >>> return a >>> pointer rather than cloning the cache? I looked at the API and >>> didn't see >>> anything that said it was copying the object and creating a local copy. >>> >>> 2. Returning and having to handle the entire contents of the servlet >>> context >>> could imply alot of overheard, I would think....at least presuming your >>> copying the context each time a page is called in ordert to obtain a >>> local >>> copy of something, in this case an XsLT Transformer object. >>> >>> Am I misunderstanding your suggestion, or how this would work? >>> >>> Thanks. >>> Neal >>> >>> >>> -----Original Message----- >>> From: Siddharth [mailto:siddharth@pun.cmc.net.in] >>> Sent: Tuesday, September 17, 2002 10:30 PM >>> To: Tomcat Users List >>> Subject: Re: Caching / Cloning >>> >>> >>> Neal, >>> I have never worked with XSLT but I can show you the way where you >>> can have >>> an >>> initial copy of ServletContext which you can use independently. >>> Interface ServletContext has a mathod called >>> getContext(java.lang.String uripath) returns ServletContext >>> You can use this method by giving uripath of same application to get >>> a copy >>> of cache. >>> >>> I hope, This suggestion may help you. >>> Siddharth >>> >>> >>> ----- Original Message ----- >>> From: neal >>> To: Tomcat Users List >>> Sent: Wednesday, September 18, 2002 9:52 AM >>> Subject: Caching / Cloning >>> >>> >>> >>> >>>> Is there a way to make a copy of what's in my cache >>>> >>> >>> (getServletContext()) >>> >>> >>>> and make changes to that local copy, independent of whether the cached >>>> object implements Cloneable()? >>>> >>>> >>>> In order to speed up my XSLT I thought I would preload them (their >>>> Transformer objects) into app scope and simply retrieve it as >>>> needed for >>>> transforms. >>>> >>>> This works fine except I just remembered that I need to set attributes >>>> >>> >>> on >>> >>> >>>> these XsLT Transformer objects. Now, I am PRESUMING that this means >>>> >>> >>> that >>> I >>> >>> >>>> would then be locking up the servlet context each time I set one of >>>> >>> >>> these >>> >>> >>>> parameters so then it seems I should clone() the object locally. That >>>> >>> >>> way >>> I >>> >>> >>>> could set the params locally without affecting (or locking) the cached >>>> version). BUT Transfomer does not appear to implement the Cloneable() >>>> interface. >>>> >>>> Is there a way around this? Am I by any chance wrong about what's >>>> >>> >>> actually >>> >>> >>>> happening here? Can anyone make a suggestion? >>>> >>>> Here's what I'm doing basically: >>>> >>>> ServletContext application = getServletContext(); >>>> application.setAttribute("TEMPLATES_HASH",templates); >>>> (where templates is a Hashtable containing Transformer objects) >>>> >>>> >>>> Thanks. >>>> Neal >>>> >>>> >>>> -- >>>> To unsubscribe, e-mail: >>>> >>> >>> >>> >>> >>>> For additional commands, e-mail: >>>> >>> >>> >>> >>> >>> -- >>> To unsubscribe, e-mail: >>> >>> For additional commands, e-mail: >>> >>> >>> >>> -- >>> To unsubscribe, e-mail: >>> >>> For additional commands, e-mail: >>> >>> >> >> >> >> >> >> _________________________________________________________________ >> Send and receive Hotmail on your mobile device: http://mobile.msn.com >> >> >> -- >> To unsubscribe, e-mail: >> >> For additional commands, e-mail: >> >> >> >> -- >> To unsubscribe, e-mail: >> >> For additional commands, e-mail: >> >> >> >> > > > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: