The jdbc spec seems vague on that (as on all multi-threaded behavior)
and can probably be interpreted either way. I'm not sure what other
jdbc drivers do. I can take a look at the MySQL driver.
Our concern is that even if the close *should* interrupt the current
operation, it should do so cleanly instead of causing a protocol
violation. I haven't been able to craft anything worse than an error
on close, but just looking at the code, there's definitely a lack of
synchronization on the shared PGStream object there that could
potentially lead to worse problems.
On Mon, Aug 24, 2009 at 5:48 PM, Oliver Jowett<oliver@opencloud.com> wrote:
> Maciek Sakrejda wrote:
>> We've found some synchronization issues around PGStream in
>> QueryExecutorImpl and ProtocolConnectionImpl. Specifically, while
>> QueryExecutorImpl synchronizes all its uses off PGStream,
>> ProtocolConnectionImpl uses the same PGStream directly when close() is
>> called. This can easily cause protocol-level errors and,
>> theoretically, at least, bad data shoved into a COPY IN query while
>> the actual Connection.close() is ignored. This doesn't just affect
>> COPY, though--anything that causes writes to the QueryExecutorImpl's
>> pgStream could be affected.
>>
>> The only thing I've achieved so far is protocol-level errors, but
>> that's a serious enough issue on its own.
>>
>> It's not immediately clear how to fix this, since we don't want to
>> synchronize PGStream itself. Should ProtocolConnectionImpl just
>> delegate to QueryExecutorImpl on close() perhaps, with
>> QueryExecutorImpl handling the actual writes to PGStream?
>
> What's the expected behaviour when Connection.close() is called
> concurrently with other work happening on the connection - should the
> close interrupt the current operation?
>
> -O
>
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda@truviso.com
www.truviso.com
