Are deadlocks preventable?

[Gili]

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

[Ryan How]

Well you could get a global database lock with every transaction, it
would kill concurrency, but you'd be ensured to never get a deadlock :P

Sorry, not very helpful :), but no-one else has replied on here :)

> --
> 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 h2-database...@googlegroups.com.
> To post to this group, send email to h2-da...@googlegroups.com.
> Visit this group at http://groups.google.com/group/h2-database?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Noel Grandin]

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.

[Thomas Mueller]

Hi,

Yes, if it's a problem, you could lock one table at a time (using "select ... for update").

Regards,

Thomas

--

[cowwoc]

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 <cow...@bbs.darktech.org> 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 h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
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 h2-database...@googlegroups.com.

[Thomas Mueller]

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

[cowwoc]

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