I've been seeing many blogs and articles against single-version optimistic locking, which can cause a transaction to abort even if two concurrent transactions don't modify the same records.
While dynamic updates can help, many fear to use it because of performance issues (for very large tables). I was wondering if we can have something like a SubEntity, which has the Entity identifier, some properties and a version of its own. A regular Entity could be mapped to include multiple such SubEntities, just that those cannot overlap in properties. Instead of having only one optimistic locking version, we could have one version for each SubEntity. Whenever a property becomes dirty, Hibernate will check the SubEntity it belongs to, and it will use that particular version. This is a realistic scenario since many business use cases don't necessarily overlap when updating a certain Entity. Besides the concurrency control advantage, we could offer the possibility of fetching less data for a particular use case. Now Hibernate must fetch a whole Entity in order to modify just some fields (we lose both on read-performance and on write-performance this way too). Let me know what you think of this. Vlad _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
