Hi Sven,
Sven Efftinge wrote:
Hi Armin,
I wrote a test for this, now.
Unfortunately I wrote it against my application, because I haven't
installed the OJB test suite yet ;(
The test starts n threads. Each thread creates a PersistentBroker,
retrieves 4 instances of an entity and then checks some
Hi again,
sorry, this make things better, but does not really solve the problem.
regards,
Armin
Armin Waibel wrote:
Hi Sven,
I can reproduce your problem. It's a really nasty concurrency
materialization problem when using global/shared caches and an object
was materialized first time:
Say we
: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 3:00 PM
To: OJB Users List
Subject: RE: [PB API] concurrency problems
Maybe I am missing somethingbut why not wait until the entire tree
(collections and references) has been materialized before pushing the
object on the
Armin Waibel dijo:
> Hi Sven,
>
> I can reproduce your problem. It's a really nasty concurrency
> materialization problem when using global/shared caches and an object
> was materialized first time:
> Solution is to set attribute 'refresh="true"' in all
> reference-descriptor. This force OJB to lo
:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 1:31 PM
To: OJB Users List
Subject: Re: [PB API] concurrency problems
Hi Sven,
I can reproduce your problem. It's a really nasty concurrency
materialization problem when using global/shared caches and an object
was materialized first time:
S
Hi Sven,
I can reproduce your problem. It's a really nasty concurrency
materialization problem when using global/shared caches and an object
was materialized first time:
Say we have a class Account with reference to Buyer, Buyer has a
reference to Address and Address has a reference to AddressT
Hi Armin,
I just figured out that you were right.
The problem I had occured because I tried to access "not yet loaded"
proxy references after closing the broker.
But what happens in my test?
Does this occur because OJB sets auto-retrieve to false sometimes?
Ho can we handle such a behaviour?
regar
I just changed ObjectCacheClass from DefaultImpl to EmptyImpl.
Without caching the test doesn't fail.
I think this happens because the threads don't have to share the objects
in this case.
Sven
Sven Efftinge wrote:
Hi Armin,
I wrote a test for this, now.
Unfortunately I wrote it against my appli
Hi Armin,
I wrote a test for this, now.
Unfortunately I wrote it against my application, because I haven't
installed the OJB test suite yet ;(
The test starts n threads. Each thread creates a PersistentBroker,
retrieves 4 instances of an entity and then checks some references for
each entity.
Wh
Hi Sven,
I don't know if your problem rely on a concurrency problem. Between rc4
and rc5 I changed handling of DB resources in RsIterator class.
Now OJB is very strict in closing used resources. All resources will be
released when
- PB instance was closed
- PB commit call is done
- PB abort call
10 matches
Mail list logo
