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.
Chris -----Original Message----- From: Aron Lurie [mailto:[email protected]] Sent: Thursday, 16 June 2011 5:44 AM To: [email protected] Subject: Re: Speeding up commit Also, 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 eliminated. -Aron 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: >> http://openjpa.208410.n2.nabble.com/Speeding-up-commit-tp6474341p6479 >> 404.html Sent from the OpenJPA Users mailing list archive at >> Nabble.com. >
