[
https://issues.apache.org/jira/browse/ASTERIXDB-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yingyi Bu closed ASTERIXDB-1947.
--------------------------------
Resolution: Fixed
> Revisit thread safety in FileMapManager
> ---------------------------------------
>
> Key: ASTERIXDB-1947
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-1947
> Project: Apache AsterixDB
> Issue Type: Improvement
> Components: STO - Storage
> Reporter: Yingyi Bu
> Assignee: Abdullah Alamoudi
>
> Synchronizations on FileMapManager (e.g., synchronized register/unregister,
> and ConcurrentHashMap for id2namemap and name2idmap) is added in change
> https://asterix-gerrit.ics.uci.edu/#/c/1840/.
> However, this class seems 50%-baked -- there are some synchronizations but
> there could be inconsistency between id2nameMap and name2IdMap. For example,
> register/unregister
> are not atomic -- a caller can lookupFileId(...) while the file hasn't fully
> registered or unregistered, and possibly open an non-existent file?
> I think we probably don't want thread-safety for FileMapManager at all, since
> the call sites anyway has to orchestrate multiple steps and make sure the
> bigger block is synchronized:
> E.g. BufferCache.openFile(...):
> {noformat}
> synchronized (fileInfoMap) {
> if (fileMapManager.isMapped(fileRef)) {
> fileId = fileMapManager.lookupFileId(fileRef);
> } else {
> fileId = fileMapManager.registerFile(fileRef);
> }
> openFile(fileId);
> }
> return fileId;
> {noformat}
> Even if FileMapManager is thread-safe, it doesn't help and you still have to
> synchronized on the big block to make sure atomicity of the sequence of
> isMapped/lookup/register. Most call sites have a similar pattern. Thoughts?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
