public final class RowLock extends Object
Row locks can be explicitly acquired in order to serialize edits to a given row. This feature may disappear from HBase in the future, so try not to use it if you can.
While a row is locked, no one else can edit that row. Other concurrent attempts to lock that row will block until the lock is released. Beware that the blocking happens inside the RegionServer, so it will tie up a thread of the RegionServer. If you have many clients contending for the same row lock, you can literally starve a RegionServer by blocking all its IPC threads.
Row locks can't be held indefinitely. If you don't release a row lock after
a timeout configured on the server side, the lock will be released
automatically by the server and any further attempts to use it will yield an
UnknownRowLockException.
public long holdNanoTime()
This is a best-effort estimate of the time the lock has been held starting from the point where the RPC response was received and de-serialized out of the network. Meaning: it doesn't take into account network time and time spent in the client between when the RPC was received and when it was fully de-serialized (e.g. time spent in kernel buffers, low-level library receive buffers, time doing GC pauses and so on and so forth).
In addition, the precision of the return value depends on the
implementation of System.nanoTime() on your platform.