Hi Chen, We used to support dataset level locks and lock escalation on the NCs but we stopped doing that at some point. IIRC we did that as there was no reason to escalate. However, the interfaces didn’t change. AFAIK the only way to lock a dataset today is to acquire the lock on the metadata entry of the dataset.
Hope this helps (and I also hope that someone will correct me if I remember incorrectly) Cheers, Till > On Feb 25, 2018, at 10:05, Chen Luo <[email protected]> wrote: > > It seems the link is deleted by the email...Here is the link for > FlushDatasetOperationDescriptor: > > https://github.com/apache/asterixdb/blob/5070d633eaee536c20706e59891a44a6257d8bd8/asterixdb/asterix-runtime/src/main/java/org/apache/asterix/runtime/operators/std/FlushDatasetOperatorDescriptor.java#L82 > > > >> On Sun, Feb 25, 2018 at 10:04 AM, Chen Luo <[email protected]> wrote: >> >> Hi Devs, >> >> I saw a few places where we've used -1 as the entity hash value during >> locking, and there is one comment saying that "lock the dataset granule" in >> FlushDatasetOperatorDescriptor [1]. However, after checking the source code >> of ConcurrentLockManager, I didn't see any places that actually support >> dataset granule locking. I also wrote a test case to perform a dataset S >> lock and then ingest data, which fails because data ingestions can still go >> through. I was wondering do we actually support dataset granule locking >> right now? >> >> >> >> >> [1] >> >> https://github.com/apache/asterixdb/blob/5070d633eaee536c20706e59891a44a6257d8bd8/asterixdb/asterix-runtime/src/main/java/org/apache/asterix/runtime/operators/std/FlushDatasetOperatorDescriptor.java#L82 >> >>
