db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: CollectionProxy problems
Date Sat, 20 Dec 2003 09:06:24 GMT
Hi ARmin,

good idea, I'll recheck with the user!

uc,
Thomas

Armin Waibel wrote:
> Hi,
> 
> as a side note, when H/L sequence manager was used and in 
> connection-pool descriptor attribute 'whenExhaustedAction' is set to 
> 'block' (wait for connection if connection-pool is exhausted) the 
> application can freeze under heavy load. Could you exclude this?
> 
> regards,
> Armin
> 
> whenExhaustedAction
> 0 - fail when pool is exhausted
> 1 - block when pool is exhausted
> 2 - grow when pool is exhausted
> 
> Thomas Mahler wrote:
> 
>> Hi all,
>>
>> I've been currently trying to assist a user who uses his own derived 
>> versions of CollectionProxies.
>>
>> We observeed a locking situation in the following setup:
>>
>> 1. One thread starts a very long running broker query.
>>
>> 2. In a second query perform some actions that trigger the resolution 
>> of a collection proxy.
>>
>> 3. Thread 2 hangs until thread 1 is finished. It continues to work 
>> (i.e. materialize the proxy) once thread 1 is finished.
>>
>> The evil seems to be in CollectionProxy.getBroker:
>>
>>    protected synchronized PersistenceBroker getBroker() throws 
>> PBFactoryException
>>     {
>>         PersistenceBroker broker;
>>         if (getBrokerKey() == null)
>>         {
>>             /*
>>             arminw:
>>             if no PBKey is set we throw an exception, because we don't
>>             know which PB (connection) should be used.
>>             */
>>             throw new OJBRuntimeException("Can't find associated 
>> PBKey. Need PBKey to obtain a valid" +
>>                     "PersistenceBroker instance from intern resources.");
>>         }
>>
>> //**** this seems to cause the problem
>>         // first try to use the current threaded broker to avoid blocking
>>         broker = 
>> PersistenceBrokerThreadMapping.currentPersistenceBroker(getBrokerKey());
>> //**** problem zone end
>>
>>
>>         // current broker not found, create a intern new one
>>         if(broker == null)
>>         {
>>             if (m_broker == null)
>>             {
>>                 m_broker = 
>> PersistenceBrokerFactory.createPersistenceBroker(getBrokerKey());
>>                 // TODO: Better way?
>>                 needsClose = true;
>>                 broker = m_broker;
>>             }
>>         }
>>         return broker;
>>     }
>>
>> If we comment out the marked line everything works fine!
>>
>> I don't understand the original comment
>> // first try to use the current threaded broker to avoid blocking
>>
>> in what way could the usage of the currently bound broker instance 
>> help to avoid which kind of blocking?
>>
>> Before changing the mentioned line I'd prefer to understand the 
>> consequences...
>>
>> As I could see with my very eyes that two separate thread suffered a 
>> locking situation I got some doubts about the 
>> PersistenceBrokerThreadMapping.
>>
>> Is it really a safe thing to use? any ideas?
>>
>> Thomas
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message