[
https://issues.apache.org/jira/browse/RANGER-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428719#comment-17428719
]
Xuze Yang commented on RANGER-3472:
-----------------------------------
[~madhan] , thank you for your reply. Compared to adding locks in create policy
methods, I also think that apply unique-key constraint on column is a better
implement way. You mentioned a solution above: apply unique-key constraint on
column x_policy.resource_signature. As you mentioned above, this approach will
have problems in the following scenarios:
1. Create the same resource policy with status of disabled.
2. Create the same resource policy under different services in the same
warehouse.（eg：Two services named default-HDFS1 and default-HDFS2 can exist in
HDFS warehouse. It's reasonable to create a policy in default-HDFS1 even if the
same policy already been created in default-HDFS2 ）
3. Create the same resource policy under different zones.
I think a better way is to apply unique-key constraint on four columns -
'resource_signature', 'service', 'zone_id' and 'is_enabled', just like below
statement:
{code:java}
UNIQUE KEY `x_policy_UK_resource_service_zone_enabled`
(`resource_signature`,`service`, `zone_id`, `is_enabled`){code}
If we apply this unique-key constraint, above problems will be resolved(one
problem still exist : We can only create a disabled state policy at most). Do
you think this is a reasonable solution?
> The createPolicy() method is not thread safe. In another word, we can create
> policies with same resources when creating policies concurrently
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RANGER-3472
> URL: https://issues.apache.org/jira/browse/RANGER-3472
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Affects Versions: 2.1.0
> Reporter: Xuze Yang
> Priority: Major
>
> In our production environment, we happen to find that two policies exist with
> the same resources.In this case, when we want to modify either policy, ranger
> doesn't allow this operation and throws message like "*Error Code : 3010
> Another policy already exists for matching resource: policy-name=[hhh9],
> service=[default-Hdfs]*".
> I go through the source code about create policy, find that the
> createPolicy() in class ServiceREST is not thread safe. When we create
> policies concurrently, we may create several policies with the same resources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
