DB deadlock issue [message #297519] |
Fri, 01 February 2008 04:02 |
rballal
Messages: 12 Registered: February 2008
|
Junior Member |
|
|
Hi
I have a table with unique key contraint enabled for 3 feilds (combinationally unique).
We have multiple threads inserting data into the table parallally.
This leads to deadlock over a period of time.
What would be the best way to hanlde this?
Thanks,
rballal
|
|
|
|
|
Re: DB deadlock issue [message #297531 is a reply to message #297523] |
Fri, 01 February 2008 04:23 |
rballal
Messages: 12 Registered: February 2008
|
Junior Member |
|
|
Sorry i missed one information here, to achieve better performance we dont commit the data immediately after INSERT , we wait for n records (each thread waits for n records )and then commit the data.
|
|
|
|
Re: DB deadlock issue [message #297701 is a reply to message #297519] |
Sat, 02 February 2008 11:15 |
|
Kevin Meade
Messages: 2103 Registered: December 1999 Location: Connecticut USA
|
Senior Member |
|
|
So... don't take this the wrong way, but I think you are lying to us.
I am no expert on deadlock, but unless you are doing something "special", I do not know how "just inserts" can cause deadlock. From my experience, deadlock always involves getting locks in the database either by DELETE or by UPDATE or by SELECT ... FOR UPDATE. You have not said you are doing either in your code.
The only time I think inserts can actually be a cause of deadlock is when you are using BITMAP indexes. But here again you have not indicated you are using this feature. Here is a link that talks a little about this:
http://www.akadia.com/services/ora_bitmapped_index.html
Lastly you say you are using parallel threads, but lets be clear here, you are using "concurrent transactions". You are not infact using Oracle parallel inserts as if you were you would not be able to commit after X rows. Thus your scenario is that you have multiple transactions running conncurrently, all trying to insert data at the same time.
So, what exactly are you not telling us?
Also, what is the mechanism you use to decide what rows are given to each insert process? That is, how do you split the incomming data up across your transactions?
I suggest the placement of some logging in your code so you can see where it is actually "deadlocking".
Kevin
|
|
|
|
|
Re: DB deadlock issue [message #297727 is a reply to message #297726] |
Sun, 03 February 2008 00:58 |
rballal
Messages: 12 Registered: February 2008
|
Junior Member |
|
|
Pls advice on how to avoid these kinds of deadlocks?.
I understand one solution would be to commit immediately after inserting data, but here we want to achieve better performance that is our application must be able to insert the data at the rate of >500 records per sec, which we could not achieve using immediate commit, but with deffered commit (commit after n records are inserted ) we are able to achieve this.
Only when we get duplicate records due to retransmission of packets we are having this issue of deadlock.
Looking for your inputs on this.
Thanks a lot for all your help
rb
|
|
|
|
|
|
|
Re: DB deadlock issue [message #298062 is a reply to message #298023] |
Mon, 04 February 2008 20:51 |
rleishman
Messages: 3728 Registered: October 2005 Location: Melbourne, Australia
|
Senior Member |
|
|
One possibility is to make sure that rows with the same key are always processed by the same thread.
So if you have 4 threads, instead of randomly dividing the rows amongst them, use a deterministic method. eg. Keys starting with "1" go to thread number 1. Or you could use the ORA_HASH() function.
Ross Leishman
|
|
|
|
|
|
|
|
|
|
Re: DB deadlock issue [message #298443 is a reply to message #298441] |
Wed, 06 February 2008 02:13 |
|
Michel Cadot
Messages: 68716 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
Quote: | Is it allowed to say that in this case it is clearly a badly designed/written one?
|
That is what I say since my first post.
Regards
Michel
|
|
|