[
https://issues.apache.org/jira/browse/HBASE-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010760#comment-14010760
]
ramkrishna.s.vasudevan commented on HBASE-11126:
------------------------------------------------
bq.preGetForDeleteVersion needs a better name. What are you doing with this new
hook?
I would suggest prePrepareTimeStampForDeleteVersion?
This hook will be needed in case of Visibility Deletes handling. In case of
cells
C1(r, f, cq) at TS = 101 , Vis expression = A&B
C1(r, f, cq) at TS = 102, Vis expression = A
C1(r, f, cq) at TS = 103, Vis expression = A&C
If suppose a delete column with latest version is specified and the cell
visibility is A, then this should delete the latest version of the Cell with A
as the visibility expression which is TS = 102. Currently the server on seeing
a delete column with latest version would just update the Delete Cell with 103.
Now this can be done under preDelete() but again the problem of not obtaining
the row lock would come into picture. Hence this change may be needed. Also I
think we could add isReplay or not flag before calling this hook.
bq.In the Javadoc did you mean "Called before the server ... "
Yes.. Good catch.
bq.Why are you moving completeMemstoreInsert and beginMemstoreInsert into the
inner try?
if the code was added in the 'try' block before the current 'try' block in the
patch, then if we just return out from the new hooks then the update lock
obtained would not be released. Hence moved them to the try block.
Will update the patch and post a new one ASAP.
> Add RegionObserver pre hooks that operate under row lock
> --------------------------------------------------------
>
> Key: HBASE-11126
> URL: https://issues.apache.org/jira/browse/HBASE-11126
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.99.0, 0.98.3
> Reporter: Andrew Purtell
> Assignee: ramkrishna.s.vasudevan
> Attachments: HBASE-11126.patch, HBASE-11126_1.patch,
> HBASE-11126_new_2.patch, HBASE-11126_new_3.patch
>
>
> The coprocessor hooks were placed outside of row locks. This was meant to
> sidestep performance issues arising from significant work done within hook
> invocations. However as the security code increases in sophistication we are
> now running into concurrency issues trying to use them as a result of that
> early decision. Since the initial introduction of coprocessor upcalls there
> has been some significant refactoring done around them and concurrency
> control in core has become more complex. This is potentially an issue for
> many coprocessor users.
> We should do either:\\
> - Move all existing RegionObserver pre* hooks to execute under row lock.
> - Introduce a new set of RegionObserver pre* hooks that execute under row
> lock, named to indicate such.
> The second option is less likely to lead to surprises.
> All RegionObserver hook Javadoc should be updated with advice to the
> coprocessor implementor not to take their own row locks in the hook. If the
> current thread happens to already have a row lock and they try to take a lock
> on another row, there is a deadlock risk.
> As always a drawback of adding hooks is the potential for performance impact.
> We should benchmark the impact and decide if the second option above is a
> viable choice or if the first option is required.
> Finally, we should introduce a higher level interface for managing the
> registration of 'user' code for execution from the low level hooks. I filed
> HBASE-11125 to discuss this further.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
