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

[Steve Ebersole]

On Wed, Nov 18, 2015 at 6:08 AM Vlad Mihalcea <mihalcea.vlad at 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?