Ok, so it looks like MySQL at least *intends to* wait for all
statements to finish executing before closing the connection. I don't
believe this is actually accomplished, since some things synchronize
on the MySQL Connection object itself, whereas some synchronize on a
separate mutex Object it exposes through a getMutex() method, but
that's sort of irrelevant to this discussion.
I'm not quite sure what the right behavior with respect to close()
should be. If we wait for all statements to finish executing, we could
be waiting for a very long time (especially in the case of an open
COPY or something silly like "SELECT pg_sleep(1000000)"). If, on the
other hand, we cancel all still-executing queries and in-progress COPY
operations, the burden of coordinating this falls to the user, which
is somewhat unfortunate. The second choice is probably more
reasonable--the jdbc API says that close()
"Releases this Connection object's database and JDBC resources
immediately instead of waiting for them to be automatically released."
and it would be tough to interpret "immediately" as "block until
everything currently executing is done".
I'm not that familiar with the FEBE protocol (I'll look into this as
well), but we don't need to cancel regular queries explicitly, right?
The Terminate message is always valid, except in COPY mode? If that's
the case, we only need to ensure that the various PGStream messages
are sent atomically (which is currently *not* the case in the case of
Terminate), and handle COPY specially (by issuing CopyFail followed by
Terminate). I'm happy to start work on a patch if we find an approach
we agree on.
Thanks,
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda@truviso.com
www.truviso.com