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":
http://vladmihalcea.com/2014/12/08/the-downside-of-version-less-optimisti...
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 <steve(a)hibernate.org> wrote:
On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.vlad(a)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-h...
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?