Oops I haven't committed the XML EntityResolver code yet. I have been busy
working on my pipeline configuration -- a testament to the quality of
babeldoc, it works! Once I commit the XML EntityResolver code, you will be
able to make it work like this (and while it works, it is more like a good
prototype than anything else, and thus subject to change):
- in your babeldoc environment make a domify/config.properties that says
useDtdCache=true
- create a directory called dtdcache in the current working directory
- run your pipeline stages! You can verify that DTDs are getting cached by
inspection of the dtdcache directory.
Let me know if you see any performance improvement -- I definitely do but
the documents I parse reference about 171 dtds (lots of nesting).
Incidentally, I modified my pipeline configuration from this:
XPathSplitter->XPathExtractor->SqlWriter
to this:
XslTransform->SqlWriter
and it really flies. So I used to split up the XML, extract values from it,
then write each row to the database. Now I just transform the XML into a
bunch of SQL statements and run them. Its much faster and it might be a
good pattern in general.
-Jonathan
-----Original Message-----
From: Bruce McDonald [mailto:br...@mc...]
Sent: Wednesday, July 23, 2003 7:33 PM
To: Leech, Jonathan; bab...@li...
Subject: Re: [Babeldoc-devel] perils of synchronization in
PooledJdbc.java
Jonathan,
I haven't heard from you in some time - how is it going? The work that you
have done on babeldoc in recent weeks and months has been excellent. I am
hoping to see your work on the xml entity resolver.
regards,
Bruce.
On Thursday 10 July 2003 06:42 pm, Leech, Jonathan wrote:
> I think we need to remove synchronization from the checkIn() and
checkOut()
> methods of PooledJdbc.java, and here's the reason why: It causes deadlock
> every time the connection pool is exhausted.
>
> Example:
> - All database connections in the pool are being used by various threads.
> - A thread calls checkOut(), which locks the PooledJdbc object, and the
> connection pool is waiting for a checkin.
> - As the various threads finish using their database connections, they
call
> checkIn(), but are locked out.
>
> The only problem I see with it doing it is that there's a chance that
> multiple threads could ask for the first connection, which calls
> setupJdbc(), and that might be not well behaved. I think moving the
> setupJdbc to the default constructor would handle this.
>
> Thoughts?
>
> -Jonathan
|
