[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Thread-safe SAX parsing (was Re: Java based XML parsers for server use.)

  • From: roddey@u...
  • To: xml-dev@i...
  • Date: Mon, 10 May 1999 10:43:29 -0600

sax thread safety

> > * mads@p...
> > |
> > | Are there any Java based XML parsers that are suitable for server
> > | side use? One of the primary requirements for such a parser is that
> > | should be thread safe. i.e.., more than one thread should be able to
> > | use the parser simultaneously.
> >
> > I have to confess that I haven't looked at this aspect of parsers
> [snip]
>You could start with this:

>Once the parse begins, the SAX parser itself controls flow of
>processing, so I cannot imagine how another thread could mess up the
>actual parsing (there's no way to change the parser's state externally
>once it begins parsing).  To be perfectly safe, you could always
>synchronize on the InputSource and/or the InputStream/Reader that you
>are using.
>Perhaps people with more experience in Java concurrent programming can
>take (friendly) shots at this suggestion.

We take the approach that thread safety, at least from the perspective of
parsing, should be at the actual parser/scanner instance level. So, you cannot
have two threads using the same parser, but you can have as many threads as you
want, each with its own parser. This makes the system almost totally
synchronization free, so its fast and cheap. There are a few static data bits,
but they are generally read only once initialized, so there is really little to
no synchronization required.

But that's just for parsing. The events that come out of the scanner/parser are
in the context of that one thread that is running that parse, so that is no
problem as well as long as the recipient handles any synchronization on the
target data structures. DOM of course is a another specification of worms and
has its own issues. It would often be the case that multiple threads would be in
a DOM structure all at the same time, so it generally has to be overly
synchronized and more granular level (i.e. it costs whether you are using it or

>From a server's perspective though, the 'thread per parser' scenario seems
optimal. It would basically equate to a 'thread per served client', which also
is very common and useful. In that kind of situation, there would be very little
synchronization required as relates to the XML parser. We don't forsee any
useful reason, that's worth the gotchas it raises for everyone else, to have
multiple threads in a single parser at a time.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.