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

["Hadoop QA (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SENTRY-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15977728#comment-15977728 ] 

Hadoop QA commented on SENTRY-1710:
-----------------------------------

Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12864360/SENTRY-1710.00-sentry-ha-redesign.patch against sentry-ha-redesign.

{color:green}Overall:{color} +1 all checks pass

{color:green}SUCCESS:{color} all tests passed

Console output: https://builds.apache.org/job/PreCommit-SENTRY-Build/2548/console

This message is automatically generated.

> 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
>         Attachments: SENTRY-1710.00-sentry-ha-redesign.patch
>
>
> As discussed in SENTRY-1643 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)