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