asked on Preventing deadlock.
I have two tasks, both invoke the same proc in package mypkg.
The proc inserts into a table. Thus we have two sessions inserting into same table through a proc in mypkg.
Thus, Task1 and Task2 tasks failed due to deadlock issue,
Logs:
25-MAY-12 04.51.56.680350000 AM "[do_stuff]{}
Stack:
ORA-00060: deadlock detected while waiting for resource
Backtrace:
ORA-06512: at "DEV.mypkg", line 123"
25-MAY-12 04.51.44.221277000 AM "[do_stuff]{}
Stack:
ORA-00060: deadlock detected while waiting for resource
Backtrace:
ORA-06512: at "DEV.mypkg", line 123"
both tasks finished successfully on rerun induvidually.
What can i do to prevent such deadlock issues when two sessions call the same proc in a package.
The proc inserts into a table. Thus we have two sessions inserting into same table through a proc in mypkg.
Thus, Task1 and Task2 tasks failed due to deadlock issue,
Logs:
25-MAY-12 04.51.56.680350000 AM "[do_stuff]{}
Stack:
ORA-00060: deadlock detected while waiting for resource
Backtrace:
ORA-06512: at "DEV.mypkg", line 123"
25-MAY-12 04.51.44.221277000 AM "[do_stuff]{}
Stack:
ORA-00060: deadlock detected while waiting for resource
Backtrace:
ORA-06512: at "DEV.mypkg", line 123"
both tasks finished successfully on rerun induvidually.
What can i do to prevent such deadlock issues when two sessions call the same proc in a package.
Oracle Database
Last Comment
Sean Stuber
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Locking seems to be a good idea, however, if two sessions both get called, both will try to obtain a lock on the table, out of which one will succeed, what will happen to the other package - will it keep trying to obtain a lock until package 1 ends
If you can explain what these inserts are for we can likley offer better advice.
If they are inserts into some sort of staging table, I would not suggest table locks. Why make the other session wait when it really doesn't need to? Unless this is the desired behavior.
If they are inserts into some sort of staging table, I would not suggest table locks. Why make the other session wait when it really doesn't need to? Unless this is the desired behavior.
>>> - will it keep trying to obtain a lock until package 1 ends
you can choose what will happen. It can either wait until the lock is released - this is what I assume you want to happen. Or it can exit with an error.
you can choose what will happen. It can either wait until the lock is released - this is what I assume you want to happen. Or it can exit with an error.
deadlocks can happen in a few ways
it always depends on what the code actually does
> so what code are you using ?
it always depends on what the code actually does
> so what code are you using ?
ASKER
My code insert into table as already mentioned
>>My code insert into table as already mentioned
We get that. What we would like to know is more about the process and what happens to this data after it is inserted.
We have provided several ways to get around the deadlock. The more information you can provide about the process the better advice we can provide.
We get that. What we would like to know is more about the process and what happens to this data after it is inserted.
We have provided several ways to get around the deadlock. The more information you can provide about the process the better advice we can provide.
ASKER
A good example i saw on locking is here:
http://jeffkemponoracle.com/2005/10/19/user-named-locks-with-dbms_lock/
Any other simple example?
It has a merge statement:
merge into mytable a
using (select col1,
col2,
col3,
from myview b
inner join
mytable c
on b.col1 = c.col1
and c.mydate = b.mydate
where b.col4 is not null
and b.mydate = p_mydate) s
on (a.rowid = s.rid)
when matched then
update set a.col1 = s.col1,
a.col2 = 'ABC',
a.mydate = s.mydate,
a.col3 = s.col3;
http://jeffkemponoracle.com/2005/10/19/user-named-locks-with-dbms_lock/
Any other simple example?
It has a merge statement:
merge into mytable a
using (select col1,
col2,
col3,
from myview b
inner join
mytable c
on b.col1 = c.col1
and c.mydate = b.mydate
where b.col4 is not null
and b.mydate = p_mydate) s
on (a.rowid = s.rid)
when matched then
update set a.col1 = s.col1,
a.col2 = 'ABC',
a.mydate = s.mydate,
a.col3 = s.col3;
So you have decided to go with manual locks?
I've never used them so will have to defer to the other Experts.
I've never used them so will have to defer to the other Experts.
going with the user locks, something like the original code in Jeff Kemp's article should work fine. The followup stuff only applies to his specific scenario with triggers.
For your usage (at least as I understand it) simply allocate a particular handle and request it.
The only thing I'd change is the release on commit, as noted in the article, set that to FALSE.
For your usage (at least as I understand it) simply allocate a particular handle and request it.
The only thing I'd change is the release on commit, as noted in the article, set that to FALSE.
or
use a global temorary table for the inserts. This is sort of why they were created. Only the session that inserts into them can see the rows and they are automatically cleaned up when the session ends (or commits depending on how you create the table).