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