openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "C N Davies" <>
Subject RE: Speeding up commit
Date Thu, 16 Jun 2011 05:58:12 GMT
Actually on that point I think I agree that I have seen this very behaviour
myself. OpenJPA gets confused if  change B then change A then commit A (with
cascade all set on A), I commonly get detached entity errors in reference to
B.  I ended up working around that by persisting B, reread it then
persisting A. I got so tired of this issue I have been using Hibernate a lot
more lately.


-----Original Message-----
From: Aron Lurie [] 
Sent: Thursday, 16 June 2011 5:44 AM
Subject: Re: Speeding up commit

When class A has a property of type class B, and both instances are
persisted, the B instance does not need to be proxied because any mutation
made on the B instance will be noticed by the entity manager since it is
persisted. However, I believe the current behavior is to create a proxy for
the B instance. If I am right, this is a source of redundancy that could be


On 6/15/2011 3:11 PM, Aron Lurie wrote:
> Based on the documentation I've read, it didn't occur to me as a user 
> that proxying stemmed from detachment. I had the concept in mind that 
> proxying was a two part process: attachment - or putting the proxy in 
> place of the original object, and detachment - or replacing the 
> original object.
> Just my 2 cents.
> Anyways, I've found a way to speed up the proxying process, by caching 
> the result of my objects getters, since they take time to produce the 
> return value.
> -Aron
> On 6/15/2011 11:47 AM, Pinaki Poddar wrote:
>>> it still attaches proxies during commit,
>> It was my bad. Looks like your environment is ready to absorb changes.
>> Please update on trunk -- that has a correct NONE logic that will 
>> bypass proxy on commit.
>> -----
>> Pinaki
>> --
>> View this message in context: 
>> 404.html Sent from the OpenJPA Users mailing list archive at 

View raw message