Maybe we should just go "all the way" and have a per-column version? ;)
Anyway, like I said... 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 at 11:35 PM Vlad Mihalcea <mihalcea.v...@gmail.com> wrote: > Actually both merge() and update() can still cause a "write skew" > phenomena, especially when using dynamic updates + OptimisticLockType DIRTY > < > https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#DIRTY > > > or OptimisticLockType ALL > < > https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotations/OptimisticLockType.html#ALL > > > . > Let's say I have an imaginary Product entity with a price and a quantity, > and when I "purchase" it, I simply decrease its quantity (considering that > the price doesn't change). > > 1. I load the Product with price 9.99 and quantity 5 in one Hibernate > Session/HTTP request > 2. Bob comes and changes the price to 14.99 > 3. I go back to place my order and I will use merge(). I will load the > Product with the new price but I won't be aware of that, and I'll issue a > dynamic-update on quantity, by simply decreasing. > > This anomaly can currently be fixed by @Version implementation. Neither > DIRTY or ALL can detect this anomaly, because they relate to the latest > state (Bob's change) and not what I used to see in my first transaction. > That's how sub-versions would fix this because, by grouping properties > joined by a business transaction rule (price-quantity-discount), we could > eliminate conflicts between distinct groups of properties and only raise an > optimistic locking exception when a property is changed within the same > group (price-quantity-discount). > > If we don't even consider something like this, we can still split the > tables into smaller ones to achieve the same goal. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
