In addition to modify the business logic, with the same thread there another way?
If it is mysql can modify the transaction isolation level, oracle, how?
Mainly to write code too food, so much shit to me, how the whole?
Two threads, two transactions, at the same time remove the same record cause a deadlock, you have any good solution

CodePudding user response:

Oracle's single line form the delete is ascending level locking, multi-threaded delete does not exist a deadlock, will only be suspended,

CodePudding user response:

reference 1st floor kingkingzhu response:

oracle's single line form the delete is ascending level locking, multi-threaded delete does not exist a deadlock, will only be suspended,

Pending will sign up for a long period of time of deadlock errors, I know that is not in the traditional sense of the deadlock,

CodePudding user response:

Pending a long time, should be your program timeout, or the session has expired, not deadlock,

Deadlock is two sessions, formed a wait for each other to release resources,

CodePudding user response:

I know that brothers,

* * * 2018-03-18 01:25:39. 378
DEADLOCK DETECTED (ORA - 00060)

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a
Deadlock due to user error in the design of an application
Or The from issuing incorrect AD - hoc SQL. The following
Information may aid in determining the deadlock:

Deadlock graph:
-- -- -- -- -- -- -- -- -- Blocker (s) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Waiter (s) -- -- -- -- -- -- -- -- --
The Resource Name process session doesn waits process session doesn waits
TX - 000 f001b - 002 dc2e3 51, 177 X 234 S
TX - 00150001-000 ef565 20 234 X 51 177 S

The session 177: DID the 0001-0033-0000 0 b9b session 234: DID the 0001-0014-0000 1985
The session 234: DID the 0001-0014-0000 1985 session 177: DID the 0001-0033-0000 0 b9b

Rows waited on:
The Session 177: obj - rowid=00013437 - AAAWIFAGGAADLFQAAA
(a dictionary objn - 78903, the file - 390, block 831824, slot 0)
The Session 234: obj - rowid=00013437 - AAAWIFAGGAADLcrAAA
(a dictionary objn - 78903, the file - 390, block 833323, slot 0)

-- -- -- -- -- Information for OTHER waiting sessions -- -- -- -- --
The Session 234:
Sid: 234 ser: 39915 audsid: 18424972 user: 85/IPRA
USR/- flags_idl x100045 flags: (0) : (0 x1) BSY/-/-/-/-/-
Flags2: (0 x40009) -/-/INC
Pid: 20 O/S info: user: oracle, term: UNKNOWN, ospid: 54067284
Image: oracle @ P740_01_LA
The client details:
O/S info: user: appadm, term: ospid: SQ - IPRA - APP - 1, 7388:8008
Machine: SQ \ SQ - IPRA - APP - 1 program: Server WinUi. Job. Exe
The current SQL:
The delete from IWBTAX t where iaxksq in (select KSQ from
(select ipdprf as PRF, ipdfrm as FRM, ipdtkt as TKT, ipdksq as KSQ from iwbpdt
Union select ivtprf as PRF, ivtfrm as FRM, ivttkt as TKT, ivtksq as KSQ from iwbvtk
Union select irtprf as PRF, irtfrm as FRM, irttkt as TKT, irtksq as KSQ from iwbrtk)
The where (PRF, FRM, TKT) in ((: PRF, : FRM, : TKT)))

-- -- -- -- -- End of information for OTHER waiting sessions -- -- -- -- --

Information for THIS session:

-- -- -- -- -- the Current SQL Statement for this session (sql_id=620 uuhpsnkb6u) -- -- -- -- --
The delete from IWBTAX t where iaxksq in (select KSQ from
(select ipdprf as PRF, ipdfrm as FRM, ipdtkt as TKT, ipdksq as KSQ from iwbpdt
Union select ivtprf as PRF, ivtfrm as FRM, ivttkt as TKT, ivtksq as KSQ from iwbvtk
Union select irtprf as PRF, irtfrm as FRM, irttkt as TKT, irtksq as KSQ from iwbrtk)
The where (PRF, FRM, TKT) in ((: PRF, : FRM, : TKT)))

But how do you explain this?

CodePudding user response:

Deadlock problem is generally logical design has a problem, find the SQL to develop modified,
To avoid multiple sessions at the same time dealing with the same data at the same time,

CodePudding user response:

reference 5 floor liuzhijian2008x reply:

deadlock problem is generally logical design has a problem, find out the SQL to develop modified,
To avoid multiple sessions at the same time dealing with the same data at the same time, the

Delete library development early to run

CodePudding user response:

Are you delete away a full table scan or index also delete action if there is a master-slave off-balance-sheet key data to be processed

CodePudding user response:

refer to 7th floor kingkingzhu response:

are you delete away a full table scan or index also delete action if there is a master-slave off-balance-sheet key data to be processed

I know go index can lead to a deadlock, the question now is I want to know is there a way to solve the problem of multithreading concurrent delete the same,,,
Because delete a lot of table data, and can't disorderly delete index,
And concurrent execution, occasionally, a terrible wrong

CodePudding user response:

Your this kind of circumstance is not met me to but has examined the most point to watch the foreign key problems
You have checked the trace to Google

CodePudding user response:

The delete from IWBTAX t where iaxksq in (select KSQ from
(select ipdprf as PRF, ipdfrm as FRM, ipdtkt as TKT, ipdksq as KSQ from iwbpdt
Union select ivtprf as PRF, ivtfrm as FRM, ivttkt as TKT, ivtksq as KSQ from iwbvtk
Union select irtprf as PRF, irtfrm as FRM, irttkt as TKT, irtksq as KSQ from iwbrtk)
The where (PRF, FRM, TKT) in ((: PRF, : FRM, : TKT)))


Here in three bind variables, the value of the two sessions to provide is not the same, and provided many times at least value,

Session 1, C1, C2, C3, session 2 D1, D2, D3, two sessions are not submitted,
At this point, the session 1 and D1, D2, D3, session 2 provides C1, C2 and C3.

This session will be formed,

A development also can't find it? If no, then don't make multiple sessions delete data together,

CodePudding user response:

Logically, multiple reply operation the same resources at the same time, why on the database to find methods to solve well,nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull