Message-ID: <gh-pgjdbc-pgjdbc-943-c328621281@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Mon, 11 Sep 2017 18:43:14 +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: vlsi
X-GitHub-Comment-Id: 328621281
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-328621281
Content-Type: text/plain; charset=utf-8

>The general consensus is that you should NOT share connections across threads, and in my opinion, a connection pool should be more than enough for most cases.

Fully agree.

> Should be thread-safe, but beyond that, it's implementation dependent.

I agree, however it turns out lots of uses depend on `Statement.getWarnings` thread safety. E.g. https://github.com/pgjdbc/pgjdbc/issues/927

>So the question here should be if the 95% (or more) of the use cases works without synchronization/thread-safety, does it's worth the performance implications to cover the 5% of the cases?

I think added synchronization would not matter much performance-wise. Nor it would matter support-wise: some of the methods have already been synchronized, so it could make sense to make them aligned.