RE: [Babeldoc-devel] perils of synchronization in PooledJdbc.java

[Leech, J. <jl...@vi...>]

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