config:
- occ open
- use FileSystemBasedLock
- mdt is open in write defualt
there has three job, jobA, jobB, jobC, these three jobs are running at the same time.
jobA get lock success, jobB has been trying to get lock, jobC also try to get lock.
jobB failed because can not get lock, but it delete lock file when close write client, now, jobC will get lock, it cause concurrent problem.
In our case, jobC will rollback jobA mdt commit which has been succeed commited. So, the data table timeline has the repleaseCommit instance, but mdt without this update, it cause partition path be deleted and can not reserve the latest file split in our case
JIRA info
Comments
14/Mar/25 17:07;yihua;I don't think the current implementation of FileSystemBasedLock guarantees only one writer gets the lock because atomic creation is not enough. The conditional writes need to be supported by the file system and used in the lock provider. See new RFC-91 for the new design: #12927;;;
config:
there has three job, jobA, jobB, jobC, these three jobs are running at the same time.
jobA get lock success, jobB has been trying to get lock, jobC also try to get lock.
jobB failed because can not get lock, but it delete lock file when close write client, now, jobC will get lock, it cause concurrent problem.
In our case, jobC will rollback jobA mdt commit which has been succeed commited. So, the data table timeline has the repleaseCommit instance, but mdt without this update, it cause partition path be deleted and can not reserve the latest file split in our case
JIRA info
Comments
14/Mar/25 17:07;yihua;I don't think the current implementation of
FileSystemBasedLockguarantees only one writer gets the lock because atomic creation is not enough. The conditional writes need to be supported by the file system and used in the lock provider. See new RFC-91 for the new design: #12927;;;