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.vlad(a)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/annotatio...
>
or OptimisticLockType ALL
<
https://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/annotatio...
>
.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev