[ 
https://issues.apache.org/jira/browse/HBASE-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ramkrishna.s.vasudevan updated HBASE-11126:
-------------------------------------------

    Attachment: HBASE-11126.patch

> 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)

Reply via email to