[jira] [Created] (SENTRY-1710) Reduce datanucleus key cache size for MSentryPermChange and MSentryPathChange tables to avoid holes in change IDs

["Lei (Eddy) Xu (JIRA)" <ji...@apache.org>]

Lei (Eddy) Xu created SENTRY-1710:
-------------------------------------

             Summary: Reduce datanucleus key cache size for MSentryPermChange and MSentryPathChange tables to avoid holes in change IDs
                 Key: SENTRY-1710
                 URL: https://issues.apache.org/jira/browse/SENTRY-1710
             Project: Sentry
          Issue Type: Improvement
          Components: Sentry
    Affects Versions: sentry-ha-redesign
            Reporter: Lei (Eddy) Xu
            Assignee: Lei (Eddy) Xu


As discussed in SENTRY-1644 and SENTRY-1706, {{MSentryPermChange}} and {{MSentryPathChange}} tables require that {{CHANGE ID}} of such changes to be unique and consecutive.  SENTRY-1644 addressed this requirement in the application code, that requires multiple trips for each change record insertion, while it raises the possibility of collision on change ID when there are concurrently updates. 

[~LinaAtAustin] kindly suggested that the holes existed between the change ID sequence is due to the fact that {{datanuclues}}'s {{key-cache-size}} property is default to 10, so that it pre-claims 10 consecutive primary keys  for each transaction. 

http://www.datanucleus.org/products/accessplatform_4_0/jdo/value_generation.html#increment

This JIRA is going to change the key cache size to 1.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)