From pavel.rappo at gmail.com Tue May 13 18:27:29 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Tue, 13 May 2025 19:27:29 +0100 Subject: Thread interruption and concurrent close Message-ID: Is it specified how JDBC methods should react to thread interruption and concurrent closure of the connection? As a JDBC user, I'm trying to figure out my best course of action in the following scenario. A statement has been executing for a while when the application shutdown hook starts. The hook should quickly shut down everything and return. -Pavel From douglas.surber at oracle.com Thu May 15 15:41:22 2025 From: douglas.surber at oracle.com (Douglas Surber) Date: Thu, 15 May 2025 15:41:22 +0000 Subject: Thread interruption and concurrent close In-Reply-To: References: Message-ID: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> The intended way to handle this is to call Connection.abort(Executor) on the offending Connections. This method will mark the Connection as closed and return quickly. It may also schedule a task to perform any long running work appropriate to actually shutdown and clean up the Connection and its resources. Because the Connection may be in use, and thus locks held, cleaning up the Connection may not take place until the locks are released perhaps after the socket timeout. The default socket timeout is something like 15 minutes so this can take a while. Douglas Surber Connection (Java SE 23 & JDK 23) docs.oracle.com [favicon.ico] On May 13, 2025, at 11:27?AM, Pavel Rappo wrote: Is it specified how JDBC methods should react to thread interruption and concurrent closure of the connection? As a JDBC user, I'm trying to figure out my best course of action in the following scenario. A statement has been executing for a while when the application shutdown hook starts. The hook should quickly shut down everything and return. -Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: image/vnd.microsoft.icon Size: 10134 bytes Desc: favicon.ico URL: From pavel.rappo at gmail.com Fri May 16 16:50:57 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Fri, 16 May 2025 17:50:57 +0100 Subject: Thread interruption and concurrent close In-Reply-To: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> Message-ID: Okay, so Connection.abort(Executor) is a safe way to initialise the connection closure. Is there any example use of that method available? Separately, JDBC seems to be silent on threading. Those few methods that take Executor seem to have been added relatively recently. On Thu, May 15, 2025 at 4:41?PM Douglas Surber wrote: > The intended way to handle this is to call Connection.abort(Executor) on > the offending Connections. This method will mark the Connection as closed > and return quickly. It may also schedule a task to perform any long running > work appropriate to actually shutdown and clean up the Connection and its > resources. Because the Connection may be in use, and thus locks held, > cleaning up the Connection may not take place until the locks are released > perhaps after the socket timeout. The default socket timeout is something > like 15 minutes so this can take a while. > > Douglas Surber > > Connection (Java SE 23 & JDK 23) > > docs.oracle.com > > [image: favicon.ico] > > > > > On May 13, 2025, at 11:27?AM, Pavel Rappo wrote: > > Is it specified how JDBC methods should react to thread interruption > and concurrent closure of the connection? > > As a JDBC user, I'm trying to figure out my best course of action in > the following scenario. A statement has been executing for a while > when the application shutdown hook starts. The hook should quickly > shut down everything and return. > > -Pavel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: application/octet-stream Size: 10134 bytes Desc: not available URL: From db at dawnbreaks.net Mon May 19 01:47:12 2025 From: db at dawnbreaks.net (David Bullock) Date: Mon, 19 May 2025 11:47:12 +1000 Subject: Thread interruption and concurrent close In-Reply-To: References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> Message-ID: As a mere spec user, I agree that the doc could be clearer. Only #setNetworkTimeout(Executor) makes mention of an 'administrative thread' in connection with #abort(Executer), but #abort(Executor) itself is silent about this. Further, although mention of an 'administrative thread' implies that the Connection is visible to multiple threads, a class-level doc about the thread-safety of the object along the lines of: "not guaranteed to be thread safe, except for #abort(Executor) and #setNetworkTimeout(Executor)" would still be helpful. On Sat, 17 May 2025 at 02:51, Pavel Rappo wrote: > Okay, so Connection.abort(Executor) is a safe way to initialise the > connection closure. Is there any example use of that method available? > Separately, JDBC seems to be silent on threading. Those few methods that > take Executor seem to have been added relatively recently. > > On Thu, May 15, 2025 at 4:41?PM Douglas Surber > wrote: > >> The intended way to handle this is to call Connection.abort(Executor) on >> the offending Connections. This method will mark the Connection as closed >> and return quickly. It may also schedule a task to perform any long running >> work appropriate to actually shutdown and clean up the Connection and its >> resources. Because the Connection may be in use, and thus locks held, >> cleaning up the Connection may not take place until the locks are released >> perhaps after the socket timeout. The default socket timeout is something >> like 15 minutes so this can take a while. >> >> Douglas Surber >> >> Connection (Java SE 23 & JDK 23) >> >> docs.oracle.com >> >> [image: favicon.ico] >> >> >> >> >> On May 13, 2025, at 11:27?AM, Pavel Rappo wrote: >> >> Is it specified how JDBC methods should react to thread interruption >> and concurrent closure of the connection? >> >> As a JDBC user, I'm trying to figure out my best course of action in >> the following scenario. A statement has been executing for a while >> when the application shutdown hook starts. The hook should quickly >> shut down everything and return. >> >> -Pavel >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: application/octet-stream Size: 10134 bytes Desc: not available URL: From mark at lawinegevaar.nl Mon May 19 07:14:22 2025 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Mon, 19 May 2025 09:14:22 +0200 Subject: Thread interruption and concurrent close In-Reply-To: References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> Message-ID: <41d281f0-2c77-4472-b00a-80e60689270a@lawinegevaar.nl> On 19/05/2025 03:47, David Bullock wrote: > As a mere spec user, I agree that the doc could be clearer.? Only > #setNetworkTimeout(Executor) makes mention of an 'administrative thread' > in connection with #abort(Executer), but #abort(Executor) itself is > silent about this.? ?Further, although mention of an 'administrative > thread' implies that the Connection is visible to multiple threads, a > class-level doc about the thread-safety of the object along the lines > of:?"not guaranteed to be thread safe, except for #abort(Executor) and > #setNetworkTimeout(Executor)" would still be helpful. There used to be a soft requirement about thread safety in the JDBC specification (version 1.20, chapter 9 Asynchrony, Threading, and Transactions), and it was removed in JDBC 2.1. I'm not sure why it was removed, but probably because not all implementations could or wanted to do so. Basically, a connection should be used by one thread during a unit of work, and if you want to access it from multiple threads during a unit of work, beyond statement cancellation or connection abort, you need to coordinate access yourself. If only because you don't want one thread to do a lot of work, for another thread to call commit() or switch to auto-commit when the work isn't done yet. In the JDBC driver I maintain (Jaybird), I do (try to) guarantee thread safety, and it's not always pretty, and it won't even protect against a scenario like the previous paragraph. Also, there is no such thing as an "administrative thread" in JDBC. The setNetworkTimeout method only talks about an "administrator thread", and that refers to a thread *outside* of the JDBC connection (and JDBC in its entirety) that calls abort to cancel misbehaving or stuck connections (e.g. a connection pool implementation killing connections if they fail timeout checks, or maybe something that guards liveness of an application). Also, please keep in mind that JDBC is an API, and that different drivers can and do solve things differently, so the API documentation can't specify everything to death. For example, for the question that started this thread: for Type 4 (pure Java) implementations, I'd generally expect that thread interruption has an effect like stopping what it is doing and maybe even forcibly closing the connection. However, the other types, especially Type 1 and Type 2, maybe Type 3, have native components, and once you cross the barrier into native, Java thread interruption is out of the window. So, if JDBC had specified that a connection should respond to thread interruption, Type 1 and Type 2 drivers would have been a lot harder (maybe even impossible) to write. Mark -- Mark Rotteveel From davecramer at gmail.com Mon May 19 09:43:17 2025 From: davecramer at gmail.com (Dave Cramer) Date: Mon, 19 May 2025 05:43:17 -0400 Subject: Thread interruption and concurrent close In-Reply-To: References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> Message-ID: I've always assumed that the driver public API was not intended to be thread-safe. Yes there are internal threads but externally no. Dave Cramer On Sun, 18 May 2025 at 21:47, David Bullock wrote: > As a mere spec user, I agree that the doc could be clearer. Only > #setNetworkTimeout(Executor) makes mention of an 'administrative thread' in > connection with #abort(Executer), but #abort(Executor) itself is silent > about this. Further, although mention of an 'administrative thread' > implies that the Connection is visible to multiple threads, a class-level > doc about the thread-safety of the object along the lines of: "not > guaranteed to be thread safe, except for #abort(Executor) and > #setNetworkTimeout(Executor)" would still be helpful. > > On Sat, 17 May 2025 at 02:51, Pavel Rappo wrote: > >> Okay, so Connection.abort(Executor) is a safe way to initialise the >> connection closure. Is there any example use of that method available? >> Separately, JDBC seems to be silent on threading. Those few methods that >> take Executor seem to have been added relatively recently. >> >> On Thu, May 15, 2025 at 4:41?PM Douglas Surber >> wrote: >> >>> The intended way to handle this is to call Connection.abort(Executor) on >>> the offending Connections. This method will mark the Connection as closed >>> and return quickly. It may also schedule a task to perform any long running >>> work appropriate to actually shutdown and clean up the Connection and its >>> resources. Because the Connection may be in use, and thus locks held, >>> cleaning up the Connection may not take place until the locks are released >>> perhaps after the socket timeout. The default socket timeout is something >>> like 15 minutes so this can take a while. >>> >>> Douglas Surber >>> >>> Connection (Java SE 23 & JDK 23) >>> >>> docs.oracle.com >>> >>> [image: favicon.ico] >>> >>> >>> >>> >>> On May 13, 2025, at 11:27?AM, Pavel Rappo wrote: >>> >>> Is it specified how JDBC methods should react to thread interruption >>> and concurrent closure of the connection? >>> >>> As a JDBC user, I'm trying to figure out my best course of action in >>> the following scenario. A statement has been executing for a while >>> when the application shutdown hook starts. The hook should quickly >>> shut down everything and return. >>> >>> -Pavel >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: application/octet-stream Size: 10134 bytes Desc: not available URL: From mark at lawinegevaar.nl Mon May 19 09:54:34 2025 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Mon, 19 May 2025 11:54:34 +0200 Subject: Thread interruption and concurrent close In-Reply-To: References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> Message-ID: <9b19269c-ed0f-49f8-be24-f602e34f5ebc@lawinegevaar.nl> On 19/05/2025 11:43, Dave Cramer wrote: > I've always assumed that the driver public API was not intended to be > thread-safe. Yes there are internal threads but externally no. That is a driver implementation detail, not a JDBC thing. Mark -- Mark Rotteveel From mark at lawinegevaar.nl Mon May 19 09:55:47 2025 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Mon, 19 May 2025 11:55:47 +0200 Subject: Thread interruption and concurrent close In-Reply-To: <9b19269c-ed0f-49f8-be24-f602e34f5ebc@lawinegevaar.nl> References: <66C5ED88-9944-462B-BC5C-A13E17F1DF95@oracle.com> <9b19269c-ed0f-49f8-be24-f602e34f5ebc@lawinegevaar.nl> Message-ID: <8be031b6-6fe1-4425-b4c0-79cbcfe2d390@lawinegevaar.nl> On 19/05/2025 11:54, Mark Rotteveel wrote: > On 19/05/2025 11:43, Dave Cramer wrote: >> I've always assumed that the driver public API was not intended to be >> thread-safe. Yes there are internal threads but externally no. > > That is a driver implementation detail, not a JDBC thing. To be clear, I was responding to the "Yes there are internal threads but externally no.". Mark -- Mark Rotteveel