On Mon, Jun 8, 2020 at 6:51 PM Thorsten Schöning <[email protected]> wrote:
> Guten Tag Lukas Eder, > am Montag, 8. Juni 2020 um 17:41 schrieben Sie: > > > JDBC Connections cannot be shared among threads.[...] > > Is that more like a suggestion based on your experience or a hard > technical fact? > Spring and Java EE mostly implement thread bound transaction models, where you wouldn't get a Connection from another thread anyway. I must admit, I'm not sure if there's a hard requirement from the JDBC *spec* for vanilla JDBC Connections not to be shared among threads. It's just something that I've personally never seen yet. There's the following sentence in the docs I provided: > > > Committing or rolling back a transaction closes all open ResultSet > > objects and currently executing Statements, unless you are using > > held cursors. > > https://docs.oracle.com/javadb/10.8.3.0/devguide/cdevconcepts89498.html > > "ResultSet" and "Statement" is referred to in plural. Why is that not > implying parallel usage of the underlying connection? The JDBC-drivers > implement synchronization for a reason most likely as well. The linked > docs don't forbid concurrent usage as well and don't explicitly advise > to only share sequentially. > Well, there's a difference between executing statements concurrently and consuming resources concurrently. Also, there's a difference between doing things "concurrently" *on the server side* and *on the client side*. Furthermore, what does "concurrent" even mean in terms of resource consumption? Is it really possible to consume two results sets at the same time, or are the two consumptions serialized in some way? Ultimately, JDBC is a network protocol abstraction. Each JDBC call corresponds to a message sent to the server, and a response retrieved back from the server. For example, ResultSet.next() will, if the next row isn't already cached in the client, send some sort of "fetch" message to the server, fetching the next batch of rows from some "cursor" resource, i.e. a buffer that is filled by some "query execution" resource. So, indeed, there could be vendors that support some degree of true parallelism through some of these JDBC types. I don't actually know this. For most of my professional life, I've spared myself the trouble of delving into these things and followed purely thread-bound transaction models as they are much easier to reason about... -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO6G%3D4h5So3bPSUg7hEomMh-U9feBVm0KCgb0Zphp3%3DU0A%40mail.gmail.com.
