Thanks for the update. Actually they worked ok for what they were. IMHO they should never had been made public because they aren't RLL that people think of as part of transactions and isolation levels found in RDBMSs.
Had me worried there for a sec... Thx On Aug 28, 2013, at 11:22 PM, lars hofhansl <[email protected]> wrote: > Specifically the API has been removed because it had never actually worked > correctly. > > > Rowlocks are used by RegionServers for intra-region operations. > As such they are ephemeral, in-memory constructs, that cannot reliably > outlive a single RPC request. > The HTable rowlock API allowed you to create a rowlocks and hold it over > multiple RPCs, which would break if f.e. a region is moved or split. > > -- Lars > ________________________________ > From: Ted Yu <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Wednesday, August 28, 2013 8:01 PM > Subject: Re: RowLocks > > > The API is no longer a public API > > Thanks > > > On Wed, Aug 28, 2013 at 7:58 PM, Michael Segel > <[email protected]>wrote: > >> Ted, >> Can you clarify... >> Do you mean the API is no longer a public API, or do you mean no more RLL >> for atomic writes? >> >> On Aug 28, 2013, at 5:18 PM, Ted Yu <[email protected]> wrote: >> >>> RowLock API has been removed in 0.96. >>> >>> Can you tell us your use case ? >>> >>> >>> On Wed, Aug 28, 2013 at 3:14 PM, Kristoffer Sjögren <[email protected] >>> wrote: >>> >>>> Hi >>>> >>>> About the internals of locking a row in hbase. >>>> >>>> Does hbase row locks map one-to-one with a locks in zookeeper or are >> there >>>> any optimizations based on the fact that a row only exist on a single >>>> machine? >>>> >>>> Cheers, >>>> -Kristoffer >>>> >> >> The opinions expressed here are mine, while they may reflect a cognitive >> thought, that is purely accidental. >> Use at your own risk. >> Michael Segel >> michael_segel (AT) hotmail.com >> >> >> >> >> >> > The opinions expressed here are mine, while they may reflect a cognitive thought, that is purely accidental. Use at your own risk. Michael Segel michael_segel (AT) hotmail.com
