Re: [hibernate-dev] Sub entities and Multi-version support
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(a)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-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?
>