zeroshade commented on issue #64: URL: https://github.com/apache/arrow-adbc/issues/64#issuecomment-1214417469
I'll chime in from the Go database/sql package: * A Connection Object is assumed to be Stateful and will not be used concurrently by multiple Goroutines * Connections have a close method which should invalidate and potentially stop any current prepared statements and transactions, marking the connection as no longer in use. The sql package itself will maintain a free pool of connections and only calls Close when there's a surplus of idle connections, so the driver doesn't need to do its own connection caching. * Any network calls made by Close must not block indefinitely (e.g. apply a timeout) * A prepared statement is bound to a single Connection, and will not be used by multiple goroutines concurrently One thing to keep in mind though is that the semantics of Goroutines *do not* require execution on the same OS thread and are subject to the Go scheduler. This is only *really* relevant in the case where we'll use CGO to communicate with the actual C libraries. So while there are promises from the database/sql package in terms of *concurrent* usage, it can still be used my multiple different OS threads and multiple different Goroutines, just not concurrently. Go does provide a method to lock a particular goroutine to an OSthread if needed, so our thread safety guarantees will need to also address if we expect a given object to be *allowed* to be used by multiple threads (making TLS infeasible for example) or not. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
