Re: default resultset concurrency?

[Chris Cheshire]

Mark,

So if one connection runs a PreparedStatement created with ResultSet.CONCUR_READ_ONLY for a straight select, it will still block access to a record on another connection with a PreparedStatement running an update? This doesn't sound very multi-threaded-ish.

These are scheduled apps hitting the same DB as a live website. This time it occurred while two different apps were running concurrently, but could happen between an app and the website. I only found out about the problem after the fact and "show processlist" doesn't show anything relevant because all the connections had been long since closed. I was able to track it down to what caused the deadlock by the timestamps in the log files of different apps.

The longer running queries do limit first by indexed fields, but ultimately they do search on non-indexed fields and it just isn't feasible to index every field that might be included in a query.

I'll add the JDBC url params in that you mention in your blog and see what gets logged if it happens again, but it seems odd that a select (without for update) is blocking an update on another thread.

Thanks

Chris