Re: Reusing XT instances

Subject: Re: Reusing XT instances
From: Eric van der Vlist <vdv@xxxxxxxxxxxx>
Date: Sat, 29 Jan 2000 08:16:30 +0100

It won't help you much, but I would be very interested by knowing the
result of your research in this area !

I am not far advanced, but in my todo list (maybe should I say my dream
list ;) I'd like to implement a mechanism to independently cache and
reuse both the XSL sheets and the XML trees...

I think we should set up something to share the tricks around of XT
which is a wonderful tool but can be quite opaque when you want to do
beyond the first level of use.



Robert Streich wrote:
> At 09:44 PM 1/28/00 +0100, Eric van der Vlist <vdv@xxxxxxxxxxxx> wrote:
> >The XSLServlet works in a servlet environment which is multi threaded
> >and it wouldn't be safe to use the same object.
> This much, I could take care of by locking the processor to ensure sequential
> access. If this slows down access, a good appserver should create new
> servlet instances to keep up with demand.
> SAX says that a parser is reusable but not reentrant. To me, this means
> that a SAX parser is not thread-safe, so in any multi-threaded environment,
> you'd have to lock the parser.
> >However, the longest operation is the parsing of the XSLT transformation
> >which is done before the XSLProcessor is cached and therefore, this
> >parsing is reused.
> Unfortunately, I have to write this assuming that the stylesheet will be
> different for every run. tr.SheetImpl looks to be pretty well encapsulated
> and XSLProcessorImpl.loadStylesheet() replaces the current stylesheet.
> It's an interesting point that you brought up, however. It could be worthwile
> to cache the Sheet. It'd make for a lot of rigamarole, but it might be
> worth considering.
> bob
> Robert Streich
> Calico Commerce
> rstreich@xxxxxxxxxx
>  XSL-List info and archive:

Eric van der Vlist                                              Dyomedea                

 XSL-List info and archive:

Current Thread