[
https://issues.apache.org/jira/browse/PHOENIX-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720632#comment-17720632
]
Rushabh Shah commented on PHOENIX-6950:
---------------------------------------
I was about to create this jira. :)
I agree with approach#1. Even Oracle docs also suggest this.
https://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
E.g.
{code:java}
public Data get(String key) {
r.lock();
try { return m.get(key); }
finally { r.unlock(); }
}
{code}
> PhoenixDriver APIs should unlock closeLock only if thread is able to take lock
> ------------------------------------------------------------------------------
>
> Key: PHOENIX-6950
> URL: https://issues.apache.org/jira/browse/PHOENIX-6950
> Project: Phoenix
> Issue Type: Bug
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
>
> The bug surfaces rarely. We take read lock on closeLock as part of
> PhoenixDriver connect, getQueryServices, getConnectionQueryServices APIs.
> However, taking the locks is part of try block and we always try to perform
> the unlock on closeLock as part of finally block.
> If the lock could not be acquired because the current thread was interrupted,
> we should not be allowed to unlock it. We can resolve this by:
> # Allow taking read lock outside of try and deal with InterruptedException
> by throwing SQLException
> # Use additional arg in PhoenixDriver#lockInterruptibly to ensure whether
> the lock could not be obtained by the current thread and use the info while
> unlocking
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
