db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Efftinge <s...@efftinge.de>
Subject Re: closing resources
Date Sun, 01 Feb 2004 11:12:27 GMT
Hi Armin,
there are two different problems. I will name them the 
"ResourceClosedException problem" and the "[PB API] concurrency problem".
Our actual problem is the "ResourceClosedException problem" which occurs 
sometimes when a proxy should materialize the persistent object.
The "[PB API] concurrency problem" is something I found when I tried to 
write a test for the "ResourceClosedException problem".
I think, you already know why the "[PB API] concurrency problem" happens.

So my focus is on the "ResourceClosedException problem".
This is what I found out so far:
The exception is thrown only in the following case
1) Using RC5 (RC4 works)
2) Retrieving Proxies with a QueryByCriteria (Maybe other Queries 
affected, too)
3) Only with the first object from the result
4) you have to invoking some getter on references and then a getter for 
a normal property (e.g. Article.getProductGroup().getEditor().getName())
5) You have to stress the system (for example by invoking 90 threads 
which invoke the references on 1 object).
     In our web app the error occurs when I start two request and both 
request get the same object with QueryByCriteria.
6) The broker must be closed before 4)

Yesterday, I wrote a test for the OJB test suite. I used Article and 
ProductGroup but couldn't reproduce the error, so far.
Maybe because one reference is not enough so I will add a reference to 
ProductGroup (e.g. Editor) and set all three classes to proxy="dynamic".
Another difference is that we use PostgreSQL for the test which fails 
and in the OJB-test I use Hypersonic. (Maybe Hypersonic is too fast!?)
We found the error, because we have an abstraction layer for OJB with a 
method LdPersistenceManager.findObjectById().
This method used QueryByCriteria instead of getObjectByIdentity. (I 
changed it now)

regards,
Sven



Armin Waibel wrote:

> Hi Sven,
>
> just to make things clear, you don't have any problems except the 
> cache concurrency problem?
>
> regards,
> Armin
>
> Sven Efftinge wrote:
>
>> Uuuhhh....
>> didn't I mention that we built an abstraction layer for ojb?
>> When I use the abstraction layer in a test I get the error below.
>> So it is definately my fault (as mostly ;( )
>> Sorry and thank you,
>> Sven
>>
>> Sven Efftinge wrote:
>>
>>> Hi Armin,
>>> probably you are right. I just tried to find a way through the 
>>> following stacktrace:
>>>
>>> org.apache.ojb.broker.PersistenceBrokerException: 
>>> org.apache.ojb.broker.accesslayer.RsIterator$ResourceClosedException: 
>>> Resources no longer reachable, RsIterator will be automatic cleaned 
>>> up on PB.close/.commitTransaction/.abortTransaction
>>>    at 
>>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:251)

>>>
>>>    at 
>>> org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:263)

>>>
>>>    at 
>>> org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:997)

>>>
>>>    at 
>>> org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePrefetcher.java:153)

>>>
>>>    at 
>>> org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.prefetch(QueryReferenceBroker.java:836)

>>>
>>>    at 
>>> org.apache.ojb.broker.core.QueryReferenceBroker$PBMaterializationListener.beforeMaterialization(QueryReferenceBroker.java:773)

>>>
>>>    at 
>>> org.apache.ojb.broker.accesslayer.IndirectionHandler.beforeMaterialization(IndirectionHandler.java:146)

>>>
>>>    at 
>>> org.apache.ojb.broker.accesslayer.IndirectionHandler.materializeSubject(IndirectionHandler.java:335)

>>>
>>>    at 
>>> org.apache.ojb.broker.accesslayer.IndirectionHandler.getRealSubject(IndirectionHandler.java:312)

>>>
>>>    at 
>>> org.apache.ojb.broker.accesslayer.IndirectionHandler.invoke(IndirectionHandler.java:287)

>>>
>>>    at $Proxy0.getId(Unknown Source)
>>>
>>> As you can see this occurs when OJB tries to materialize a proxy.
>>> Because this part of OJB is very complex I couldn't find out where 
>>> the closed pb comes from (but I will try further ;).
>>> Maybe you can help me with that.
>>>
>>> The Stacktrace only occurs when I start multiple requests in my webapp.
>>> I couldn't write a test for this, so far.
>>>
>>> Armin Waibel wrote:
>>>
>>>> Hi Sven,
>>>>
>>>> Sven Efftinge wrote:
>>>>
>>>>> Hi Armin,
>>>>> I found the strictness in closing used resources very problematic, 
>>>>> especially when using proxies.
>>>>> Since proxies should be transparent (and so the fact that in OJB a 
>>>>> proxy is associated to a persistencebroker)
>>>>> users normally wouldn't expect an error when doing the following:
>>>>>
>>>>> PersistenceBroker broker = null;
>>>>> Persistent obj = null;
>>>>> try {
>>>>>      broker = 
>>>>> PersistenceBrokerFactory.createPersistenceBroker(pbKey);
>>>>>      obj = broker.getObjectByIdentity(anIdentity);
>>>>> } finally {
>>>>>      broker.close();
>>>>> }
>>>>> obj.getReference().getFieldVal();
>>>>>
>>>>
>>>> hmm, this shouldn't cause any problems. If the actual PB instance 
>>>> was closed, the proxy internal try to obtain a new PB instance for 
>>>> object materialization.
>>>> OJB is only strict in handling DB resources in conjunction with 
>>>> Iterator. After a PB.close(), PB.commit/abortTransaction() the 
>>>> underlying connection was released (returned to pool or closed), 
>>>> thus we should take of resources used by RsIterator, because the 
>>>> will become invalid after listed PB method calls.
>>>>
>>>>> I don't know if the problem occurs with references, 
>>>>> collection-references or both ??
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> A problem with automatic closed Iterator resoures shouldn't occur 
>>>> in conjunction with references.
>>>>
>>>>>
>>>>> Additionally the strictness is not that strict, because the error 
>>>>> doesn't occur always (only under stress?).
>>>>> So it is not easy to locate problematic code sequences.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Can you post me the stack trace of such an error? Maybe it's a 
>>>> "normal" error indicating that your resources are exhausted, e.g. 
>>>> connection-pool exhaust.
>>>>
>>>> > Couldn't we think about a different solution?
>>>> >
>>>> What do you mean?
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>> regards,
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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