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

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

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. While dynamic updates can help, many fear to use it because of performance issues (for very large tables).