Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.3K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 544 SQLcl
- 4K SQL Developer Data Modeler
- 187K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.5K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 439 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
Why the Deadlock is takes place on the table?

We are not able to insert data into the table. Although we can select data properly. The procedure on that table is continuously in running process but there is no status having fail or success.
Answers
-
Well, deadlock is result of two or more session conflict. It can't occur just in one session. You need to check deadlock graph to see what sessions are causing deadlock. In short session S1 makes changes to row R1 in table T1 but not yet commits so row is locked by session S1 . Session S2 makes changes to row R2 in table T2 but not yet commits so row is locked by session S2. Then session S1 tries to make change to row R2 in table T2 and waits for session S2 to release lock (commit/rollback) on row R2 in table T2. Meanwhile session S2 tries to make change to row R1 in table T1 and waits for session S1 to release lock (commit/rollback) on row R1 in table T1. As a result we have a deadlock - session 1 is waiting on session 2 while session2 is waiting on session 1. Oracle detects it and kills one of the sessions so the other can continue. In most cases deadlock is result of bad scheduling.
SY.