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
