Thomas,
My mistake. Okay, let's take a concrete query for example. Given:
UPDATE employee SET employee.count = employee.count+1 WHERE employee.id IN
(
SELECT employee.id FROM companies, employees WHERE companies.id IN
(
SELECT winning_companies.id FROM winning_companies
) AND employees.company_id = companies.id
)
You're saying I would need to break this down into:
1. Lock winning_companies rows: SELECT winning_companies.id FROM
winning_companies FOR UPDATE
2. Lock company rows: SELECT companies.id FROM companies WHERE
companies.id IN (query #1) FOR UPDATE
3. Lock and update employee rows: UPDATE employee SET employee.count =
employee.count+1 WHERE employee.id IN (query #2)
So we end up executing query #1 three times, query #2 two times, query
#3 one time. Obviously this example is meant to emphasize the extra
overhead.
Is this the best we can do? If you had to guess, would you expect
the overhead to be negligible due to caching?
Thanks,
Gili
On 20/05/2013 1:17 PM, Thomas Mueller wrote:
Hi,
> Last time I checked, SELECT ... FOR UPDATE ensures tables get
locked, but does not specify what in what order (for multi-table queries).
Yes, that's why I wrote: "you could lock one table at a time". Please
note the "one table at a time".
Regards,
Thomas
On Mon, May 20, 2013 at 6:55 PM, cowwoc <[email protected]
<mailto:[email protected]>> wrote:
Thomas (and Noel),
Last time I checked, SELECT ... FOR UPDATE ensures tables get
locked, but does not specify what in what order (for multi-table
queries). Whether for H2 or SQL as a whole, locking order for
multiple tables seems to be treated as an implementation detail.
Again, this is a guess based on what I've experienced so far.
Please let me know if I'm wrong.
After much consideration, I think I will give up and simply
push the problem out to the client:
http://stackoverflow.com/q/16628713/14731 ... Not ideal, but (I
think) it'll work.
Gili
On 20/05/2013 9:34 AM, Thomas Mueller wrote:
Hi,
Yes, if it's a problem, you could lock one table at a time (using
"select ... for update").
Regards,
Thomas
On 20/05/2013 9:29 AM, Noel Grandin wrote:
It's basically a non-problem.
In 20 years of database programming, I've never seen it myself.
For people who did see it, the recommended approach was to lock
the data by hand for the relevant queries, using LOCK TABLE or
FOR UPDATE clauses.
On Sat, May 18, 2013 at 1:58 AM, Gili <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I wanted to get your opinion regarding
http://stackoverflow.com/a/112256/14731
Is it fair to say that database deadlocks are not preventable:
1. Using portable SQL, since the SQL standard does not
specify lock ordering;
2. Using database-specific SQL code, because the execution
plan of a database might change over time.
Thank you,
Gili
--
You received this message because you are subscribed to the
Google Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected]
<mailto:h2-database%[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at
http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic
in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/h2-database/cwXlxLOdr4A/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email
to [email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:h2-database%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "H2 Database" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/h2-database/cwXlxLOdr4A/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to
[email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
