Message-ID: From: "jorsol (@jorsol)" To: "pgjdbc/pgjdbc" Date: Mon, 11 Sep 2017 20:20:47 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #943: fix: synchronize modification of shared calendar (#921) In-Reply-To: References: List-Id: X-GitHub-Author-Login: jorsol X-GitHub-Comment-Id: 328647060 X-GitHub-Comment-Type: issue_comment X-GitHub-Edited-At: 2017-09-11T20:31:04Z X-GitHub-Issue: 943 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/943#issuecomment-328647060 Content-Type: text/plain; charset=utf-8 > I agree, however it turns out lots of uses depend on Statement.getWarnings thread safety. E.g. #927 Fully agree, as I said, some methods require thread safety, and it's fine for these, but not necessarily for all. > 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. I haven't made any performance measure of performance implications of synchronization, maybe new JVM works better and the "synchronization is expensive" no longer apply, so if this is the case, then it make sense to have a thread-safety driver. Some quotes from _Java Concurrency in Practice_: > The JDBC specification does not require that Connection objects be thread-safe. > Since JDBC connections may not be thread-safe, a multithreaded application that uses a global connection without additional coordination is not thread-safe either. > Many official Java technology specifications, such as servlets and JDBC, woefully underdocument their thread safety promises and requirements.