cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: [PATCH] Re: [C2][Xalan2] Xalan2J problems under heavy load using Apache JMeter
Date Mon, 19 Mar 2001 11:59:50 GMT
Berin Loritsch wrote:

> Berin Loritsch wrote:
> 
>> Santiago Gala wrote:
>> 
>>> Berin Loritsch wrote:
>>> 
>>> I would reimplement it completely, locking the whole set of operations.
>>> A good way to start is to change public methods init(), get(), put(),
>>> dispose() to synchronized methods and wrapping the while in run() in a
>>> synchronized( this ).
>> 
> 
> I made some extensive changes to the JdbcDataSourcePool code, using the
> Avalon Lock implementation (and I corrected a synchronization error there).
> 
> I changed the Thread that monitored the class to simply create the full number
> of datasources.  It does it asynchronously, so that the pool acts like a "Future"
> object.  When the pool is fully populated, it marks itself m_initialized = true.
> When someone tries to get() and the object has not been initialized the pool
> checks to see if the asynchronous initialization is done.  If the thread has
> not been created we throw an IllegalStateException, otherwise we wait for
> the thread to finish.  We also check to see if the pool is disposed.  If not,
> then we procede to get an object.  Since we are not dealing with the possibility
> of growing the pool, the get() code is simplified a bit

Yes. It is cool to ".join()" on the initialization thread, so that 
initialization will be asynchronous, but no race condition arises.


> 
> When someone tries to put() an object, the code checks to see if the pool has
> been initialized--if not, it throws an IllegalStateException (How can we receive
> an object if it never was created?).  It then checks to see if the pool has been
> disposed.  If it has, it destroys the JdbcConnection, otherwise it returns it
> to the pool.
> 
> Hopefully this will satisfy most of the race conditions.
> 

In my tests it is completely clean now...


But, as you know, it is often easy to proof that a program HAS a bug. It 
is much more difficult to proof that it HAS NOT. :-)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message