[hibernate-dev] Pooled Optimiser Improvements

Scott Marlow smarlow at redhat.com
Thu Dec 17 10:00:49 EST 2015


A few more code changes are needed for the optimiser optimiser.

On 12/16/2015 11:04 AM, Steve Ebersole wrote:
> Well keeping in mind that IMO this should be a separate optimizer (I
> know I won't be the only one to be leery of ThreadLocals here), users
> should be able to specify this one explicitly at the
> generator-definition site.
>
> Of course not all use cases allow explicitly specifying this, which is
> sort of what you are getting at.
>   `hibernate.id.optimizer.pooled.prefer_lo` was the initial attempt at
> such use cases based on the original optimizers.  At the end of the day
> we are really just trying to determine the default optimizer to use when
> one was not explicitly specified.  Previously this was just a choice
> between POOLED and POOLED_LO (hence the boolean).  Stuart is bringing up
> a new suggestion in this decision point.  Really I think the best option
> is simply to allow the user to specify the default pooled optimizer they
> want to use : POOLED, POOLED_LO, POOLED_LOTL (fugly name).
>
> I see your latest reply now Scott.  And I don't think that changing a
> previously boolean setting to now accept Optimizer names is the correct
> solution.  I think we leave hibernate.id.optimizer.pooled.prefer_lo as
> is, although possibly deprecate it.  We'd add a new config setting for
> this: `hibernate.id.optimizer.pooled.preferred`.  If not set we fallback
> to `hibernate.id.optimizer.pooled.prefer_lo` and what we do today.
>
>
>
> On Wed, Dec 16, 2015 at 8:24 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>
>
>     On 12/16/2015 09:07 AM, Scott Marlow wrote:
>      > Any arguments against merging the
>      >
>     https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>      > change to master + 5.x?
>      >
>      > I will create a jira for this change.
>
>     HHH-10381
>
>      >
>      > Any suggestions for how to specify in persistence.xml, that the
>      > PooledThreadLocalLoOptimizer should be used?  We already have
>      > "hibernate.id.optimizer.pooled.prefer_lo", which I think can be
>     true or
>      > false.  Should we add another another similar property?  Or perhaps
>      > allow "hibernate.id.optimizer.pooled.prefer_lo" to be set to "greedy
>      > thread local optimizer" or "pooled-lotl"?  Something like:
>      >
>      > <property name="hibernate.id.optimizer.pooled.prefer_lo"
>      > value="pooled-lotl"/>
>      >
>      >
>      > On 12/15/2015 09:01 PM, Stuart Douglas wrote:
>      >> With my original patch the intention was that that the thread
>     local blocks were smaller than the incrementSize, so not every
>     thread local allocation would require a DB call. Your patch changes
>     that approach but I don't think it actually matters that much, the
>     overall performance should still be similar, and it has the
>     advantage of not needed an extra configuration value.
>      >>
>      >> Stuart
>      >>
>      >> ----- Original Message -----
>      >>> From: "Scott Marlow" <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>
>      >>> To: "Steve Ebersole" <steve at hibernate.org
>     <mailto:steve at hibernate.org>>, "Stuart Douglas" <sdouglas at redhat.com
>     <mailto:sdouglas at redhat.com>>, hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>> Sent: Wednesday, 16 December, 2015 10:15:49 AM
>      >>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>      >>>
>      >>>
>     https://github.com/scottmarlow/hibernate-orm/commits/pooledOptimizer_5.x
>      >>> is looking more correct now, if others want to look at that.
>      >>>
>      >>> On 12/15/2015 07:58 PM, Scott Marlow wrote:
>      >>>>
>      >>>>
>      >>>> On 12/15/2015 05:58 PM, Scott Marlow wrote:
>      >>>>>
>      >>>>>
>      >>>>> On 12/15/2015 05:40 PM, Scott Marlow wrote:
>      >>>>>> I changed the new test methods a bit.  [2] seems to be
>     passed the tests
>      >>>>>> but I am not understanding how PooledThreadLocalLoOptimizer
>     should
>      >>>>>> coordinate with the AccessCallback to allocate the next chunk of
>      >>>>>> sequence numbers.
>      >>>>>>
>      >>>>>> We seem to be able to call AccessCallback.getNextValue() to
>     get the next
>      >>>>>> available sequence number but how do we reserve a block of
>     5000 sequence
>      >>>>>> ids?  Am I supposed to call callback.getNextValue() an extra
>     time to get
>      >>>>>> a range of values?  Is there a separate database transaction
>     that is
>      >>>>>> used by the AccessCallback.getNextValue() calls?  I'm
>     missing something.
>      >>>>>
>      >>>>> Thinking more about this, I assume that
>     AccessCallback.getNextValue() is
>      >>>>> operating under a database transaction that we are probably
>     ending
>      >>>>> before AccessCallback.getNextValue() returns.  It also sounds
>     like the
>      >>>>> database table is tracking the "lo" value, as mentioned in the
>      >>>>> PooledLoOptimizer.  This implies that only the application
>     layer knows
>      >>>>> what the range is.  This seems like an important dependency
>     to understand.
>      >>>>>
>      >>>>> Make sense?
>      >>>>
>      >>>>
>     http://in.relation.to/2007/04/10/new-323-hibernate-identifier-generators
>      >>>> seems to explain how increment_size is used.  Since the user
>     is already
>      >>>> configured that, will look into switching to that for
>      >>>> PooledThreadLocalLoOptimizer.
>      >>>>
>      >>>>>
>      >>>>>>
>      >>>>>> Note that [2] also includes a test change to comment out a
>     few lines in
>      >>>>>> SchemaUpdateDelimiterTest, due to the compiler error that I
>     am seeing in
>      >>>>>> intellij.  Will need to remember to remove that change.
>      >>>>>>
>      >>>>>> [2]
>      >>>>>>
>     https://github.com/scottmarlow/hibernate-orm/commits/pooled-optimiser-hack-2
>      >>>>>>
>      >>>>>> On 12/15/2015 12:36 PM, Steve Ebersole wrote:
>      >>>>>>> Those tests tend to assert the increments.  We seem to
>     agree that this
>      >>>>>>> ThreadLocal one can skip gaps of values.  I'd look there first.
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> On Tue, Dec 15, 2015 at 11:34 AM Scott Marlow
>     <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>>>>>> <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>> wrote:
>      >>>>>>>
>      >>>>>>>          I'm trying to move the optimizer to
>     PooledThreadLocalLoOptimizer
>      >>>>>>>          [1].
>      >>>>>>>          We are currently failing some new unit tests,
>     which are cloned
>      >>>>>>>          from
>      >>>>>>>          existing PooledLoOptimizer tests which might be
>     part of the
>      >>>>>>>          problem.
>      >>>>>>>
>      >>>>>>>          Scott
>      >>>>>>>
>      >>>>>>>          [1]
>      >>>>>>>
>     https://github.com/scottmarlow/hibernate-orm/tree/pooled-optimiser-hack
>      >>>>>>>
>      >>>>>>>          On 12/14/2015 10:12 PM, Scott Marlow wrote:
>      >>>>>>>           >
>      >>>>>>>           >
>      >>>>>>>           > On 12/11/2015 09:30 AM, Steve Ebersole wrote:
>      >>>>>>>           >> It's hard to say without understanding the
>     scenario where you
>      >>>>>>>          are seeing
>      >>>>>>>           >> this as a problem.  I have some guesses as to
>     what may be the
>      >>>>>>>          problem,
>      >>>>>>>           >> but without understanding more about why you
>     see this as a
>      >>>>>>>          problem in
>      >>>>>>>           >> the first place it is hard to give you an
>     answer.  For
>      >>>>>>>           >> example,
>      >>>>>>>          I wonder
>      >>>>>>>           >> if for environments not using multi-tenancy
>     whether the
>      >>>>>>>           >> recent
>      >>>>>>>          changes
>      >>>>>>>           >> for the generators to support multi-tenancy
>     might be the
>      >>>>>>>          culprit.  If
>      >>>>>>>           >> that is the case, and those changes are in
>     fact the
>      >>>>>>>           >> underlying
>      >>>>>>>          cause of
>      >>>>>>>           >> the perf issues you see then I think there is
>     actually a
>      >>>>>>>           >> better
>      >>>>>>>           >> solution.  But again, its hard to say unless
>     we understand
>      >>>>>>>           >> the
>      >>>>>>>          reason
>      >>>>>>>           >> this "shows up" as a perf problem for you.
>      >>>>>>>           >
>      >>>>>>>           > As best as I can tell from looking at the current
>      >>>>>>>           > PooledLoOptimizer,
>      >>>>>>>           > versus the proposed change (to have a chunk of
>     ids per
>      >>>>>>>           > thread),
>      >>>>>>>          we went
>      >>>>>>>           > from accessing a contented lock, to instead
>     using per thread
>      >>>>>>>           > memory
>      >>>>>>>           > (eliminating the contended lock on
>      >>>>>>>           > PooledLoOptimizer.generate()).
>      >>>>>>>           >
>      >>>>>>>           >>
>      >>>>>>>           >> Until we hear more I think at this stage I'd
>     vote for a
>      >>>>>>>           >> separate
>      >>>>>>>           >> optimizer.  And maybe even not one that is
>     upstream.
>      >>>>>>>           >>
>      >>>>>>>           >> Also I agree with Scott that I am VERY leery
>     of not cleaning
>      >>>>>>>           >> up a
>      >>>>>>>           >> ThreadLocal.
>      >>>>>>>           >
>      >>>>>>>           > My mistake, as Stuart pointed out, the TL is
>     not static, so we
>      >>>>>>>          shouldn't
>      >>>>>>>           > introduce any leaks.
>      >>>>>>>           >
>      >>>>>>>           >>
>      >>>>>>>           >> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow
>      >>>>>>>           >> <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>>>>>>          <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>
>      >>>>>>>           >> <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com> <mailto:smarlow at redhat.com
>     <mailto:smarlow at redhat.com>>>>
>      >>>>>>>           >> wrote:
>      >>>>>>>           >>
>      >>>>>>>           >>      Should this be a specialized pooled
>     optimizer that is
>      >>>>>>>           >>      only
>      >>>>>>>          used in
>      >>>>>>>           >>      environments that do not suffer from
>     leaving the
>      >>>>>>>          ThreadLocal around
>      >>>>>>>           >>      after the application is undeployed?  In
>     other words,
>      >>>>>>>           >>      the
>      >>>>>>>          expectation is
>      >>>>>>>           >>      that classloader leaks with this pooled
>     optimizer are
>      >>>>>>>          expected (e.g.
>      >>>>>>>           >>      user must restart the jvm to really
>     undeploy the
>      >>>>>>>           >>      application
>      >>>>>>>           >>      completely).
>      >>>>>>>           >>
>      >>>>>>>           >>      I am thinking that there are at least
>     three typical
>      >>>>>>>           >>      situations:
>      >>>>>>>           >>
>      >>>>>>>           >>      1.  Applications are deployed in Java
>     standalone
>      >>>>>>>           >>      edition.
>      >>>>>>>          Generally,
>      >>>>>>>           >>      when the app undeploys the jvm is
>     shutting down.
>      >>>>>>>           >>
>      >>>>>>>           >>      2. Applications are deployed as part of
>     some container
>      >>>>>>>          (e.g. an EE
>      >>>>>>>           >>      server) and the Hibernate jars are on the
>     global
>      >>>>>>>          classloader path (or
>      >>>>>>>           >>      something like that).  On each shared
>     container thread,
>      >>>>>>>          there would be
>      >>>>>>>           >>      one Optimizer for all deployed
>     applications.  I wonder
>      >>>>>>>           >>      if
>      >>>>>>>          instead, we
>      >>>>>>>           >>      would want one Optimizer instance per
>     Hibernate
>      >>>>>>>           >>      SessionFactory
>      >>>>>>>           >>      associated with the many container threads?
>      >>>>>>>           >>
>      >>>>>>>           >>      3. Applications are deployed as part of
>     some container
>      >>>>>>>          (e.g. an EE
>      >>>>>>>           >>      server) and the Hibernate jars are
>     deployed with the
>      >>>>>>>          application. The
>      >>>>>>>           >>      ThreadLocals are associated with threads
>     that are shared
>      >>>>>>>           >>      by
>      >>>>>>>          different
>      >>>>>>>           >>      deployed applications. The application
>     classloader
>      >>>>>>>           >>      contains the
>      >>>>>>>           >>      Hibernate classes. Each deployed
>     application has its own
>      >>>>>>>          Optimizer
>      >>>>>>>           >>      threadlocal. On each shared container
>     thread, there
>      >>>>>>>           >>      would
>      >>>>>>>          be one
>      >>>>>>>           >>      Optimizer per application (since each
>     application has
>      >>>>>>>           >>      its
>      >>>>>>>          Optimizer TL).
>      >>>>>>>           >>         Like (2), there would be sharing of
>     the same
>      >>>>>>>           >>         Optimizer
>      >>>>>>>          with the many
>      >>>>>>>           >>      application session factories.  Should we
>     instead have
>      >>>>>>>           >>      an
>      >>>>>>>          optimizer per
>      >>>>>>>           >>      session factory?
>      >>>>>>>           >>
>      >>>>>>>           >>      Scott
>      >>>>>>>           >>
>      >>>>>>>           >>      On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>      >>>>>>>           >>       > Hello,
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > I have been working on a change to the
>     pooled
>      >>>>>>>           >>       > optimizer
>      >>>>>>>          that we
>      >>>>>>>           >>      have been seeing good performance results
>     with.
>      >>>>>>>           >>      Basically
>      >>>>>>>          it hands
>      >>>>>>>           >>      out blocks of ID's to a thread local,
>     rather than having
>      >>>>>>>           >>      every
>      >>>>>>>           >>      thread contend on the lock every time an
>     ID is required.
>      >>>>>>>           >>       >
>      >>>>>>>           >>       >
>      >>>>>>>           >>
>      >>>>>>>
>     https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > What would I need to do to get a
>     change like this in?
>      >>>>>>>           >>       > In
>      >>>>>>>          particular:
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > - Does it need to be a new type of
>     optimizer, or is
>      >>>>>>>          modifying the
>      >>>>>>>           >>      existing one like I have done OK?
>      >>>>>>>           >>       > - How should it be configured?
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > I am happy to do up a PR for this, but
>     I am just not
>      >>>>>>>          really sure
>      >>>>>>>           >>      what would be required to get it to a
>     point where it
>      >>>>>>>           >>      would be
>      >>>>>>>           >>      acceptable for inclusion.
>      >>>>>>>           >>       >
>      >>>>>>>           >>       > Stuart
>      >>>>>>>           >>       >
>     _______________________________________________
>      >>>>>>>           >>       > hibernate-dev mailing list
>      >>>>>>>           >>       > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>      >>>>>>>           >>       >
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >>       >
>      >>>>>>>           >>
>     _______________________________________________
>      >>>>>>>           >>      hibernate-dev mailing list
>      >>>>>>>           >> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>          <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>>
>      >>>>>>>           >>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >>
>      >>>>>>>           > _______________________________________________
>      >>>>>>>           > hibernate-dev mailing list
>      >>>>>>>           > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>>>           > <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>>>>>>           >
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>>           >
>      >>>>>>>
>      >>>>>> _______________________________________________
>      >>>>>> hibernate-dev mailing list
>      >>>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>>
>      >>>>> _______________________________________________
>      >>>>> hibernate-dev mailing list
>      >>>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>>
>      >>>> _______________________________________________
>      >>>> hibernate-dev mailing list
>      >>>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>>
>      >>>
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list