You can try implementing the Object Pool pattern [Grand98]. You can store
multiple Xerces instances in the pool and as your threads need them they can
check out a parser and check it back in when they are finished.
Dane Foster
Equity Technology Group, Inc
http://www.equitytg.com.
954.360.9800
----- Original Message -----
From: "Swanson, Brion" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 8:13 AM
Subject: RE: Multi threading
I have a loosly-related example of how we overcame this particular
issue. Here, we have a publishing process that takes raw text,
transforms it into some very rudimentary XML and then further
transforms that XML into a "fuller" XML document.
We're dealing with gigabytes of data in this process and one
stream is obviously not sufficient to run through this data in a
reasonable amount of time. Our solution was to create a "splitter"
and a "conjoiner" on two ends of a multi-streamed publishing system.
Basically the data comes into the 'splitter' as a stream and is
'split' into N streams - each of which runs an instance of our
publishing system. The output from the publishing system conceptually
runs into the 'conjoiner' which puts the documents back into some
particular order after the processing is finished (or at least after
a long enough delay that you're fairly certain all the closely-related
documents have been published).
I hope this helps you by giving you some idea of what has been done.
We looked into trying to make everything thread-safe, but realized as
Andy has already stated, that this is not possible (or at the very least
not worth the effort).
Good luck!
--------------
Brion Swanson - West Group / Rochester, NY
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: Andy Clark [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 27, 2001 5:31 AM
To: [EMAIL PROTECTED]
Subject: Re: Multi threading
Cormac Mullally wrote:
> Is this Xerces Java Parser 1.4.3 Multi threaded.
No, Xerces is not "multi-threaded" -- it does not use
multiple threads. However, if you mean "is Xerces thread-
safe?" then the answer is again no. And I believe that
most parsers are the same in this respect.
Parsing an XML document is a serial process. When you start
parsing a document, you need to wait until the parser has
finished parsing (or an error occurs) before you can re-use
the same parser instance.
Therefore, if your application is multi-threaded, then each
thread should have its own parser instance and not try to
share the same one. Or at least not use the same one at the
same time. But this requires synchronization to make sure
that the threads don't step on each other's toes.
> If not is there one available.
I don't think that you're going to find one. But you can
solve this problem in your application. I'm sure that there
are lots of people on the xerces-j-user mailing list that
have had to tackle the same problem and can offer you
advice (and perhaps source code).
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
