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

[Vlad Mihalcea]

Hi Gunnar,

The best article on this subject is this one:

http://www.anyware.co.uk/2005/2012/11/12/the-false-optimism-of-gorm-and-hibernate/

Another one which captures the same idea, although it's not as good as the
former one:

https://dzone.com/articles/jpa-in-case-of-asynchronous-processing

I proposed an application-level solution to this problem myself:


http://vladmihalcea.com/2014/11/10/an-entity-modelling-strategy-for-scaling-optimistic-locking/

which splits a table based on write-concerns, to minimize the chance of
getting write conflicts.

I was not implying secondary tables, I was thinking of grouping properties
towards a specific version so that the same table can have multiple
versions.

Sometimes, the optimistic locking failure can be a "false positive". If I
have a Product entity with a description and a price, one transaction
updating the price could fail because someone has changed a type in the
description.
The current optimistic locking approach is an all-or-nothing solution,
because if only one trivial field changes, all concurrent transactions
using the previous versions will fail.

So yes, we can achieve this by splitting the table in multiple sub-tables,
but to fetch the whole entity back, we would have to join all sub-tables,
which has a performance impact on its own.

Vlad

On Wed, Nov 18, 2015 at 12:52 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> 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
>