XOM API for Processing XML with Java

[Brendan.Johnston AT wellsfargo.com]

I think this a problem worth addressing in some way.

I measured (and based on the measurements did) the thread local thing for
Xerces DOM on a high volume site.

While doing it I had a queesy feeling that I was doing an optimization
that was not warranted by the requirements.
  "I don't cache StringBuffer's, why am I caching a parser."
It was a web app so the code to cache was yukky (Thread Local).

I am paranoid about "session bleed" and hate the risk.

Providing a XOM Builder/Cache pool tool may be useful in getting people like
me over the feeling that they are being tasteless.

Alternatively the documentation could say:

  (This thing) is slow to create, close to 2ms on an (X), and not thread
safe.  It is slow to create because of (this).  So we recomend you use
(these) strategies under (these) circumstances.

Alternatively you could just get rid of the overhead.  I don't think
changing constructors to static creates is a step towards a good solution.
Why can't you pool whatever is expensive under the covers and still provide
new.

Brendan



-----Original Message-----
From: xom-interest-bounces AT lists.ibiblio.org
[mailto:xom-interest-bounces AT lists.ibiblio.org]On Behalf Of Wolfgang
Hoschek
Sent: Friday, August 13, 2004 12:19 PM
To: xom-interest AT lists.ibiblio.org
Subject: RE: [XOM-interest] static Builder.create methods instead of
const ructors?


>
>> I can't judge the overhead required for a builder.  But by analogy, 
>> app
>> servers do pool database connections - for which to open incurs high
>> overhead.  And they make a huge difference in performance.  If 
>> builders also
>> incur such overhead and many are needed and used concurrently, then 
>> pooling
>> would make sense for them as well.
>>
>
> Absolutely. I'm just trying to understand why that should be done
> inside XOM rather than inside the application. If there's something
> inside XOM that would prevent builders from being pooled, that would
> be a real concern; but I don't think there is any such problem.
> -- 
>

I didn't imply that xom somehow prevents builders from beeing pooled.

What I was saying is that pooling isn't that trivial for most casual 
users (who knows how to use ThreadLocal properly?), and so they don't 
do it. The result may be XOM being perceived as inefficient which is a 
bit unfortunate.
I gave some advise including working code for those who'd like to think 
about the problem. Feel free to misread/ignore advise with a 
"trivial/none of my business/out of scope" attitude.

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest