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 can be achieved with @SelectBeforeUpdate. Personally I am inclined to vote -1 to this at the moment, but I am interested to hear what others might think. On Wed, Nov 18, 2015, 10:17 AM Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > 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-downside-of-version-less-optimistic-locking/ > > Only the @Version optimistic locking works with detached objects because > the version is embedded in the entity itself. > The @DynamicUpdate works only for entities that are fetched and modified > within the same Session, but once you detach the entity, the previous state > is lost and so you won't be able to use the previous state in the WHERE > clause so to detect an entity change. One workaround is the EXTENDED > PersistenceContext, but that's usually associated o Java EE (Spring doesn't > really offer it right out of the box). > > Does it make sense? > > Vlad > > On Wed, Nov 18, 2015 at 4:33 PM, Steve Ebersole <st...@hibernate.org> > wrote: > >> >> On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.v...@gmail.com> >> 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 >> >> <quote> >> This is because Hibernate caches the SQL generated for UPDATE statements >> such that it updates all the columns. One can only imagine how expensive >> this is in network and DB terms with large objects. >> </quote> >> >> Essentially he is upset about Hibernate's choice of a default value for a >> particular setting, ignoring that: >> 1) hey, its actually a setting that you can actually change >> 2) the performance impact of the flip side is far bigger in cases when >> you don't need it. >> >> The rest of this section goes on to talk about flipping dynamic update to >> be enabled by default and that probably circumventing the need for >> optimistic locking at all. Talk about "overly optimistic"! Not to mention >> he completely misses the fact that Hibernate can couple dynamic update with >> a custom optimistic locking strategy that uses the changed fields in the >> optimistic lock check (rather than a dedicated version column). >> >> So like I said, I stopped reading about there... >> >> @Version is simplistic. It's kind of designed that way. And then >> Hibernate builds other strategies on top of that. So if your situation >> does not "fit the simplistic case", why are you trying to use the >> "simplistic solution"? >> >> Assuming your thought aligns with those in this article, why does >> @DynamicUpdate + @OptimisticLocking(DIRTY) not work? >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
