Re: Help on integrity constraint issue

morris_luk_at_my-deja.com (Morris Luk) wrote in message news:<e3ccc19b.0201301537.7b24cf7a_at_posting.google.com>...
> Hi Mike:
>
> Thanks for your input. I'm not sure what you're trying to refer to
> when you said "in this case" in your last sentence. Case 1, Did you
> mean since there is no answer to which way is better, you just think
> locking is more efficient? Or Case 2, you tried to say in your
> delete-insert example, locking is more efficient. Or Case 3, in my
> insert-insert example, locking is more efficient.
>
> If it's Case 1, since there is no definite answer, please provide more
> evidences to convince me that your saying is right.
>
> If it's Case 2, locking is the only solution which I won't doubt. But
> of course, this has not answered my question.
>
> If it's Case 3, why do you still think that returning an error is less
> efficient than blocking others which could potentially be deadlocking
> the system?
>
> Also, please further elaborate your use of "efficient". How do you
> measure it when you say something is more efficient than the others?
>

Hi, Morris,

When I said "in this case", I meant in both case 2 and case 3. I would just categorize them as "performing insert or update on child table".  

Maybe "efficient" is not the right word. What I meant was, by using the "lock", the server doesn't have to get the "consistent" values, so it has less work to do. I don't realy see "deadlocking the system" as a big problem because we always have to deal with this kind of problems, e.g. if session 1 and session 2 both want to update a row in a table and session 1 gets the lock first, session 2 has to wait and if session 1 never commits, session 2 has to wait for forever. But if session 1 never commits, we can fixed the application to make it commit. If session 1 dies without rollback or commits, PMON will clear the lock. Again I think there is no right or wrong way of doing this. Using the "lock" is how I would do if I had to design a system.

Thanks,
Mike Received on Thu Jan 31 2002 - 13:11:08 CST