Message-ID: <gh-pgjdbc-pgjdbc-943-c328497759@github.com>
From: "sehrope (@sehrope)" <noreply+sehrope@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Mon, 11 Sep 2017 11:10:24 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #943: fix: synchronize modification of shared calendar (#921)
In-Reply-To: <gh-pgjdbc-pgjdbc-943@github.com>
References: <gh-pgjdbc-pgjdbc-943@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: sehrope
X-GitHub-Comment-Id: 328497759
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 943
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/943#issuecomment-328497759
Content-Type: text/plain; charset=utf-8

> On the other hand, threading issues (e.g. reusing a connection across threads) are quite common, so adding some safety still makes sense.

Not if it's going to be for something that's internal or not required to be safe. Otherwise it's just added complexity and overhead.

Unless the entire usage of a Connection is thread safe there's no real gain in being partially thread safe anyway. If anything it's scarier as other unhandled edge cases would be encountered.

Better to be explicit that it's not intended to be used by multiple threads (outside of say `.cancel()`) and not deal with any of this.