You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Sven Efftinge <ld...@lohndirekt.de> on 2004/01/30 09:32:50 UTC
closing resources
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();
I don't know if the problem occurs with references,
collection-references or both ??
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.
Couldn't we think about a different solution?
regards,
Sven
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: closing resources
Posted by Armin Waibel <ar...@code-au-lait.de>.
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
Re: closing resources
Posted by Sven Efftinge <ld...@lohndirekt.de>.
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
Re: closing resources
Posted by Armin Waibel <ar...@apache.org>.
Hi Sven,
first many thanks for your test case and your patience.
Sven Efftinge wrote:
> 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.
>
yep, problem is clear now. Think I found a fix for this problem.
> 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".
I try to reproduce your test in test-suite class
...broker.MultithreadedReadTest (in CVS head)
without success (against hsql and sapDB). Maybe I'm doing something
wrong or this problem is fixed in latest CVS.
Could you try to run your test against latest CVS HEAD version of OJB?
If you don't use CVS I can send you latest ojb-jar file.
regards,
Armin
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: closing resources
Posted by Sven Efftinge <sv...@efftinge.de>.
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
Re: closing resources
Posted by Armin Waibel <ar...@code-au-lait.de>.
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
Re: closing resources
Posted by Sven Efftinge <ld...@lohndirekt.de>.
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
Re: closing resources
Posted by Sven Efftinge <ld...@lohndirekt.de>.
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
Re: closing resources
Posted by Armin Waibel <ar...@code-au-lait.de>.
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