You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "ryan rawson (JIRA)" <ji...@apache.org> on 2010/01/23 01:00:27 UTC
[jira] Created: (HBASE-2162) scanners need to obey row locks, a
modest propsal
scanners need to obey row locks, a modest propsal
-------------------------------------------------
Key: HBASE-2162
URL: https://issues.apache.org/jira/browse/HBASE-2162
Project: Hadoop HBase
Issue Type: Bug
Reporter: ryan rawson
Assignee: ryan rawson
Fix For: 0.21.0
15:54 < dj_ryan> - next:
15:54 < dj_ryan> do next on Tree in memstore get rowid
15:55 < dj_ryan> acquire read lock on rowid (wait if necessary)
15:55 < dj_ryan> snapshot the entire row worth of data from memstore into scanner
15:55 < dj_ryan> release read lock on rowid
15:56 < dj_ryan> so if we get an insert on a row after the 'do next' which would call 'next' on the
previous last value grabbed from the tree
15:56 < dj_ryan> we'd skip that one
15:56 < dj_ryan> which is fine
15:57 < dj_ryan> i guess the issue comes in when you have to next a bunch to get to the next row
15:57 < dj_ryan> but that is doable with a simple little while loop
15:57 < dj_ryan> this only applies to memstore
15:57 < dj_ryan> snapshot = hfile
15:57 < dj_ryan> since its immutable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HBASE-2162) scanners need to obey row locks, a
modest propsal
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ryan rawson resolved HBASE-2162.
--------------------------------
Resolution: Invalid
implemented/obsoleted by HBASE=-2248
> scanners need to obey row locks, a modest propsal
> -------------------------------------------------
>
> Key: HBASE-2162
> URL: https://issues.apache.org/jira/browse/HBASE-2162
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.21.0
>
>
> 15:54 < dj_ryan> - next:
> 15:54 < dj_ryan> do next on Tree in memstore get rowid
> 15:55 < dj_ryan> acquire read lock on rowid (wait if necessary)
> 15:55 < dj_ryan> snapshot the entire row worth of data from memstore into scanner
> 15:55 < dj_ryan> release read lock on rowid
> 15:56 < dj_ryan> so if we get an insert on a row after the 'do next' which would call 'next' on the
> previous last value grabbed from the tree
> 15:56 < dj_ryan> we'd skip that one
> 15:56 < dj_ryan> which is fine
> 15:57 < dj_ryan> i guess the issue comes in when you have to next a bunch to get to the next row
> 15:57 < dj_ryan> but that is doable with a simple little while loop
> 15:57 < dj_ryan> this only applies to memstore
> 15:57 < dj_ryan> snapshot = hfile
> 15:57 < dj_ryan> since its immutable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2162) scanners need to obey row locks, a
modest propsal
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804030#action_12804030 ]
ryan rawson commented on HBASE-2162:
------------------------------------
If we want to replace get with a 1 row scan, we might have to do this work. with my thoughts, it might be low cost to do a rippling lock.
Another alternative is to use a data structure that prevents half-rows from being read by scanners.
This is a dangerous area we can and should do better in imho. The time is nigh!
> scanners need to obey row locks, a modest propsal
> -------------------------------------------------
>
> Key: HBASE-2162
> URL: https://issues.apache.org/jira/browse/HBASE-2162
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.21.0
>
>
> 15:54 < dj_ryan> - next:
> 15:54 < dj_ryan> do next on Tree in memstore get rowid
> 15:55 < dj_ryan> acquire read lock on rowid (wait if necessary)
> 15:55 < dj_ryan> snapshot the entire row worth of data from memstore into scanner
> 15:55 < dj_ryan> release read lock on rowid
> 15:56 < dj_ryan> so if we get an insert on a row after the 'do next' which would call 'next' on the
> previous last value grabbed from the tree
> 15:56 < dj_ryan> we'd skip that one
> 15:56 < dj_ryan> which is fine
> 15:57 < dj_ryan> i guess the issue comes in when you have to next a bunch to get to the next row
> 15:57 < dj_ryan> but that is doable with a simple little while loop
> 15:57 < dj_ryan> this only applies to memstore
> 15:57 < dj_ryan> snapshot = hfile
> 15:57 < dj_ryan> since its immutable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2162) scanners need to obey row locks, a
modest propsal
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803963#action_12803963 ]
stack commented on HBASE-2162:
------------------------------
See hbase-1806. There we allowed that scanners did not respect row locks and doc'd that this was the case.
> scanners need to obey row locks, a modest propsal
> -------------------------------------------------
>
> Key: HBASE-2162
> URL: https://issues.apache.org/jira/browse/HBASE-2162
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.21.0
>
>
> 15:54 < dj_ryan> - next:
> 15:54 < dj_ryan> do next on Tree in memstore get rowid
> 15:55 < dj_ryan> acquire read lock on rowid (wait if necessary)
> 15:55 < dj_ryan> snapshot the entire row worth of data from memstore into scanner
> 15:55 < dj_ryan> release read lock on rowid
> 15:56 < dj_ryan> so if we get an insert on a row after the 'do next' which would call 'next' on the
> previous last value grabbed from the tree
> 15:56 < dj_ryan> we'd skip that one
> 15:56 < dj_ryan> which is fine
> 15:57 < dj_ryan> i guess the issue comes in when you have to next a bunch to get to the next row
> 15:57 < dj_ryan> but that is doable with a simple little while loop
> 15:57 < dj_ryan> this only applies to memstore
> 15:57 < dj_ryan> snapshot = hfile
> 15:57 < dj_ryan> since its immutable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HBASE-2162) scanners need to obey row locks, a
modest propsal
Posted by "ryan rawson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804193#action_12804193 ]
ryan rawson commented on HBASE-2162:
------------------------------------
actually this is solvable without locks or special data structures. a single AtomicLong should be all we need too.
> scanners need to obey row locks, a modest propsal
> -------------------------------------------------
>
> Key: HBASE-2162
> URL: https://issues.apache.org/jira/browse/HBASE-2162
> Project: Hadoop HBase
> Issue Type: Bug
> Reporter: ryan rawson
> Assignee: ryan rawson
> Fix For: 0.21.0
>
>
> 15:54 < dj_ryan> - next:
> 15:54 < dj_ryan> do next on Tree in memstore get rowid
> 15:55 < dj_ryan> acquire read lock on rowid (wait if necessary)
> 15:55 < dj_ryan> snapshot the entire row worth of data from memstore into scanner
> 15:55 < dj_ryan> release read lock on rowid
> 15:56 < dj_ryan> so if we get an insert on a row after the 'do next' which would call 'next' on the
> previous last value grabbed from the tree
> 15:56 < dj_ryan> we'd skip that one
> 15:56 < dj_ryan> which is fine
> 15:57 < dj_ryan> i guess the issue comes in when you have to next a bunch to get to the next row
> 15:57 < dj_ryan> but that is doable with a simple little while loop
> 15:57 < dj_ryan> this only applies to memstore
> 15:57 < dj_ryan> snapshot = hfile
> 15:57 < dj_ryan> since its immutable
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.