db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <ar...@code-au-lait.de>
Subject Re: closing resources
Date Fri, 30 Jan 2004 15:27:50 GMT
Hi Sven,

I can't reproduce your test.
What is different to your test?

regards,
Armin


public void testObjectMaterializationByDifferentThread_2() throws Exception
     {
         String searchCriteria = 
"testObjectMaterializationByDifferentThread_2_" + 
System.currentTimeMillis();
         prepareTestRead(searchCriteria, concurrentThreads);

         Collection accounts;
         Account account;
         PersistenceBroker broker = null;
         try
         {
             broker = PersistenceBrokerFactory.defaultPersistenceBroker();
             Criteria crit = new Criteria();
             crit.addEqualTo("name", searchCriteria);
             QueryByCriteria query = new QueryByCriteria(Account.class, 
crit);
             accounts = broker.getCollectionByQuery(query);
             Iterator iter = accounts.iterator();
             // The test fails with the first object from the list only
             // uncomment the next line and the test won't fail
             iter.next();
             account = (Account) iter.next();
             while (iter.hasNext())
             {
                 iter.next();
             }
         }
         finally
         {
             if (broker != null) broker.close();
         }

         for (int k = 0; k < loops; k++)
         {
             TestCaseRunnable tct [] = new 
TestCaseRunnable[concurrentThreads];
             for (int i = 0; i < concurrentThreads; i++)
             {
                 tct[i] = new TestHandleMaterialize(account, 
searchCriteria);
             }
             // run test classes
             runTestCaseRunnables(tct);
         }
     }




Sven Efftinge wrote:

> Hi,
> 
> we finally wrote a test for this.
> the test only fails using QueryByCriteria (getObjectByIdentity works) 
> (since we use QueryByCriteria a lot in our abstraction layer, the error 
> occurs)
> the test fails approx. every second time. (if you start 90 threads (in 
> my webapp 2 requests are enough))
> 
>    public void testClosedPB() throws Throwable {
>        KontoIF konto = null;
>        PersistenceBroker broker = null;
>        try {
>            broker = 
> PersistenceBrokerFactory.createPersistenceBroker(pbKey);
>            Criteria crit = new Criteria();
>            crit.addIn("id", Arrays.asList(new Integer[]{new Integer(32), 
> new Integer(34), new Integer(77)}));
>            QueryByCriteria query = new QueryByCriteria(Konto.class, crit);
>            List result = (List) broker.getCollectionByQuery(query);
>            Iterator iter = result.iterator();
> // The test fails with the first object from the list only
> // uncomment the next line and the test won't fail
> //            iter.next();
>            konto = (KontoIF) iter.next();
>            while (iter.hasNext()) {
>                iter.next();
>            }
>                  } finally {
>            broker.close();
>        }
>        int numthreads = 90;
>        TestRunnable[] tests = new TestRunnable[numthreads];
> 
>        for (int i = 0; i < tests.length; i++) {
>            tests[i] = new FetchPersistentObjects(konto);
>        }
>        MultiThreadedTestRunner testRunner = new 
> MultiThreadedTestRunner(tests);
> 
>        testRunner.runTestRunnables();
>    }
> 
>    class FetchPersistentObjects extends TestRunnable {
> 
>        private KontoIF konto;
> 
>        /**
>         *
>         */
>        public FetchPersistentObjects(KontoIF k) {
>            super();
>            this.konto = k;
>        }
> 
>        /* (non-Javadoc)
>            * @see 
> net.sourceforge.groboutils.junit.v1.TestRunnable#runTest()
>            */
>        public void runTest() throws Throwable {
>            assertNotNull(konto.getName());
>            assertNotNull("All kontos have a reference to an 
> interessent", konto.getInteressent());
>            konto.getInteressent().getAktiv();
>            assertNotNull(
>                "All interessents have a reference to an adresse",
>                konto.getInteressent().getAdresse());
>            konto.getInteressent().getAdresse().getFirma();
>            assertNotNull(
>                "All adresses have a reference to an adresseart",
>                konto.getInteressent().getAdresse().getAdresseart());
> 
>            assertNotNull(
>                "All adressearts have a varname",
>                
> konto.getInteressent().getAdresse().getAdresseart().getVarname());
>        }
> 
>    }
> 
> 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


Mime
View raw message