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

[Steve Ebersole]

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.vlad at 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 <steve at hibernate.org>
> wrote:
>
>>
>> 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?
>>
>
>