Re: [hibernate-dev] Sub entities and Multi-version support
Hi Vlad,
2015-11-13 23:22 GMT+01:00 Vlad Mihalcea <mihalcea.vlad(a)gmail.com>:
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.
Could you give a pointer to such blog? If a TX rolls back upon
modification of different opt-locked *records* that seems like a bug
to me.
But from the remainder of your mail it appears you mean different
*properties* of one record? So IIUC, you suggest to support a specific
opt-lock field for each secondary table of an entity. Personally I'd
say different entities should be used to model this. Could you give an
example where you think this would be helpful?
Regarding your performance concerns, lazy attributes (and the load
groups Steve discussed recently) may be helpful.
All in all, to me it seems a bit you may have attributes within one
entity which may better be modelled by several entities, each only
accessed when actually needed.
--Gunnar
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev