You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@sentry.apache.org by "Lei (Eddy) Xu (JIRA)" <ji...@apache.org> on 2017/04/20 20:50:04 UTC
[jira] [Updated] (SENTRY-1710) Reduce datanucleus key cache size
for MSentryPermChange and MSentryPathChange tables to avoid holes in change
IDs
[ https://issues.apache.org/jira/browse/SENTRY-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lei (Eddy) Xu updated SENTRY-1710:
----------------------------------
Description:
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.
was:
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.
> 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-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)