db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Efftinge <ld-developm...@lohndirekt.de>
Subject Re: closing resources
Date Fri, 30 Jan 2004 14:19:51 GMT
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


Mime
View raw message