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

[Vlad Mihalcea]

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