@keith-turner see what you mean about the access pattern now. Not sure how others feel but imho using synchronization if not necessary ( by the point you made) could slow Fluo down.
On Jan 19, 2018 3:20 PM, "GitBox" <g...@apache.org> wrote: > keith-turner commented on a change in pull request #1004: FLUO-1000 > OracleServer race conditions > URL: https://github.com/apache/fluo/pull/1004#discussion_r162755741 > > > > ########## > File path: modules/core/src/main/java/org/apache/fluo/core/oracle/ > OracleServer.java > ########## > @@ -195,18 +195,25 @@ public OracleServer(Environment env) throws > Exception { > > private void allocateTimestamp() throws Exception { > Stat stat = new Stat(); > - byte[] d = curatorFramework.getData().storingStatIn(stat).forPath( > maxTsPath); > + // FLUO-1000 > + synchronized (this) { > > Review comment: > That post is correct. However in this situation, the method is private > and only called by a synchronized public method. Therefore nothing > external can directly call the method in an unsynchronized way. It would > be fine to make the whole method synchronized if you think that makes the > code more clear. > > ---------------------------------------------------------------- > This is an automated message from the Apache Git Service. > To respond to the message, please log on GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > > With regards, > Apache Git Services >