That's exactly what happens, a single complicated result set may touch off hundreds of smaller queries, spread across a thread pool of worker-bees. In a read only transaction, I am happy to use one connection per thread, but in a dirty transaction, they need to share the connection so that the transaction visibility is correct.
Chris On Wed, Apr 21, 2010 at 3:17 AM, James Gregurich <[email protected]>wrote: > > So what do you do? Run a query on a connection, get a result set and then > process that result set on multiple threads? > > > On Apr 20, 2010, at 11:53 PM, Chris Schanck wrote: > > > The spec may not require it, but for Oracle, H2, Derby, Postgres (and I > think MySQL) Connection objects are thread safe as long as you do not try to > do "transaction interleaving", i.e., use one connection for multiple > transactions. In my case I want to run multiple queries in the same > transaction space. It doesn't by me any performance over serializing the > queries, but it buys me a ton of code clarity. > > > > For my purposes, having tested for our supported backends (H2, Postgres, > Oracle), I'm comfortable with it. > > > > Chris > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<h2-database%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. > > -- C. Schanck -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
