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

[Gunnar Morling]

Hi Vlad,

2015-11-13 23:22 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev