Re: [hibernate-dev] Sub entities and Multi-version support

That is kind of true for real re-attachment. But realize that merge() e.g. is not actually a re-attachment API. merge() first loads the state and then applies the detached state over that managed state. So @DynamicUpdate does still work. And even with real re-attachment via update() the same

Re: [hibernate-dev] Sub entities and Multi-version support

I agree that @Version is simplistic, but then we only have one choice, the @DynamicUpdate solution. Now, the @DynamicUpdate has one major drawback: it doesn't work with detached entities. In the following article I detailed how it can lead to "lost updates":

Re: [hibernate-dev] Sub entities and Multi-version support

Hi Gunnar, The best article on this subject is this one: http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/ Another one which captures the same idea, although it's not as good as the former one: https://dzone.com/articles/jpa-in-case-of-asynchronous-processing

Re: [hibernate-dev] Sub entities and Multi-version support

Hi Vlad, 2015-11-13 23:22 GMT+01:00 Vlad Mihalcea : > I've been seeing many blogs and articles against single-version optimistic > locking, which can cause a transaction to abort even if two concurrent > transactions don't modify the same records. Could you give a

Re: [hibernate-dev] Sub entities and Multi-version support

On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea wrote: > Hi Gunnar, > > The best article on this subject is this one: > > > http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/ To be honest I stop reading after I read things like This is