3 fixed typos
source | link

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that concan be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle has had for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC achieves basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that con be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC achieves basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that can be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle has had for a long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC achieves basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

2 added 64 characters in body
source | link

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that con be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC acheives basically the same thingachieves basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that con be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC acheives basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that con be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC achieves basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)

1
source | link

Deadlocks are a fact of life on all databases, and Oracle is no exception. There is no magic that con be done in this situation - it is a fundamental consequence of concurrency (letting multiple users access the data at the same time without harming integrity):

create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

What Oracle for a very long time is an excellent implementation of MVCC - read about it in the very useful Concepts guide.

I'll just add that Oracle owning InnoDB is unlikely to make much difference to how InnoDB works deep down at the level of concurrency control - although as I understand it the way they both implement MVCC acheives basically the same thing (as long as you are not mixing tables using other storage engines in your MySQL queries - though you couldn't fault InnoDB in that case)