Thread-safe SAX parsing (was Re: Java based XML parsers for server use.)
> > * 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: > [snip] >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 not.) >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...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format