Message-ID: <gh-pgjdbc-pgjdbc-194-c409074045@github.com>
From: "ringerc (@ringerc)" <noreply+ringerc@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 31 Jul 2018 02:32:25 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #194: PgJDBC can experience client/server deadlocks during batch execution
In-Reply-To: <gh-pgjdbc-pgjdbc-194@github.com>
References: <gh-pgjdbc-pgjdbc-194@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: ringerc
X-GitHub-Comment-Id: 409074045
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 194
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/194#issuecomment-409074045
Content-Type: text/plain; charset=utf-8

Agreed that it's not resolved.

I looked into using a separate thread, but couldn't find much clarity on how threads interact with JDBC drivers and what the rules are there. How would we reliably ensure our receive-pumping thread was terminated when the connection was GC'd and closed, etc. But I expect we can rely on the shared TCP socket for that.

It's probably not that hard, and likely the sensible solution. Java is already so heavily threaded that nobody's going to get upset if we spawn a thread. Some care will be required to make sure the new thread gets the same classloader as the spawning thread to work properly in containerized environments, but that's well established.

I'm a bit unsure why I dismissed a threaded solution when I looked into this before.