[
https://issues.apache.org/jira/browse/PHOENIX-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095362#comment-16095362
]
Samarth Jain commented on PHOENIX-3525:
---------------------------------------
Ah, I didn't know that. The documentation completely tripped me. I will make
sure to leave the lock acquisition as it is then.
The internal code doc does say the following though:
{code}
/**
*
* Get a row lock for the specified row. All locks are reentrant.
*
* Before calling this function make sure that a region operation has already
been
* started (the calling thread has already acquired the region-close-guard
lock).
* @param row The row actions will be performed against
* @param readLock is the lock reader or writer. True indicates that a
non-exlcusive
* lock is requested
*/
{code}
So looks like we need to provide another guard with
region.startRegionOperation().
> Cap automatic index rebuilding to inactive timestamp.
> -----------------------------------------------------
>
> Key: PHOENIX-3525
> URL: https://issues.apache.org/jira/browse/PHOENIX-3525
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Ankit Singhal
> Attachments: PHOENIX-3525_wip.patch
>
>
> From [[email protected]] review comment on
> https://github.com/apache/phoenix/pull/210
> For automatic rebuilding ,DISABLED_TIMESTAMP is lower bound but there is no
> upper bound so we are going rebuild all the new writes written after
> DISABLED_TIMESTAMP even though indexes updated properly. So we can introduce
> an upper bound of time where we are going to start a rebuild thread so we can
> limit the data to rebuild. In case If there are frequent writes then we can
> increment the rebuild period exponentially
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
