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 ca
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":
http://vladmihalcea.com/2014/12/08/the
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 because Hibernate caches th
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
I
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 pointer to such blog? If a TX ro
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).
