Message-ID: From: "jorsol (@jorsol)" To: "pgjdbc/pgjdbc" Date: Mon, 11 Sep 2017 16:35:45 +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: 328585710 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-328585710 Content-Type: text/plain; charset=utf-8 Well, thread-safety in JDBC is something that has [been](https://stackoverflow.com/questions/18897092/sharing-a-jdbc-connection-across-threads) [asked](https://stackoverflow.com/questions/9428573/is-it-safe-to-use-a-static-java-sql-connection-instance-in-a-multithreaded-syste) [many](https://stackoverflow.com/questions/1209693/is-mysql-connector-jdbc-thread-safe), [many](https://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe) [times](https://stackoverflow.com/questions/1215979/jdbc-and-threading). 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. 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? The specification don't really mention that JDBC is thread-safe, or at least not in the quick search I did for "thread". Maybe in the early versions of the specification jdbc 1.2 (1997) but not anymore, and since the implementation cover jdbc 4.0+ we should not claim it's thread-safe. It makes sense that some methods like Statement.cancel() which explicitly said in the javadoc: > This method can be used by one thread to cancel a statement that is being executed by another thread. Should be thread-safe, but beyond that, it's implementation dependent.