@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
>

Reply via email to