I have tried out the following in my local machine using jdbc/mysql:

  • step 1: conn = getNewConnection
  • step 2: stmt1 = "new statement" using connection 'conn'
  • step 3: stmt2 = "new statement" using the same connection 'conn'
  • step 4: resultSet1 = execute stmt1
  • step 5: resultSet2 = execute stmt2
  • step 6: operating on both resultset 1 and 2
  • step 7: proper closing of all resources

worked fine in my machine. Can I be sure of this behaviour always (Mysql/Postgres with JDBC )? Will there be any issue?

  • 1
    I'm unsure about JDBC & postgre, mais it's strange that "it works on my machine": PDO+PHP requires the 1st statement cursor to be closed first AFAIR, so you cannot fire the 2nd statement until then. I would do a check on your "production" first, since this questions highly depends on what your "production" environment is. – Xenos Jul 2 '18 at 8:27
  • i have tried it with JDBC and MySql...(i need to know behaviour in production either with Mysql or Postgres) @Xenos – Dinesh Kumar Jul 2 '18 at 9:13
  • 1
    Why are you executing 2 different queries at the same time anyway? If you're combining the resultsets, that would be better done in the database. If you're not combining them, you can execute them one after the other. – Kayaman Jul 2 '18 at 9:43
  • Without knowing what the "production environment" is, I think none will be able to help. – Xenos Jul 2 '18 at 9:46
  • As well as the above production env information, please tell us more about step 6 - what are you doing when you are operating on result sets? Are these asynchronous operations? – David Buttrick Jul 2 '18 at 13:04

SQL is not made for parallelism. Adding such in your code will only make things more complex, and possibly slower.

For now, focus on writing non-parallel code. When finished, you may need to ask the question of "how can I make this faster", with the sub-question of "would parallelism help". The former question may involve indexes, reformulation of the query, merging two queries into one, etc. Parallelism (in the application) is only rarely the 'right' way to approach SQL work.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.