OOFS

[Chris Bitmead uid(x22068)]

>> Object level locking is also very fast and efficient. It is also
>
>Please explain how, in a way that requires no source code change
>(i.e. look at all your source code for which objects are used]

Sorry?  Regardless of page vs object locking, how you're gonna lock
something without source code?

Oh, you're thinking of getting write locks when you change something?
Not nice. Might as well just say "Please Please give me a deadlock".

Typical scenario - 

You read a whole lot of objects, do some processing, and then decide
to change something - Too Late! Someone else got a read lock on that
object too and oops they also want to update the object. This happens
all the time. In fact it's pretty much the default way things work
out.

The only correct way of doing it is to state your intentions up front
- yes I'm afraid you do have to write code, and ask for the lock you
are going to want.

>> Concurrency isn't the issue. False locking problems and false
>> deadlocks are the issue.
>> What you gonna do if someone "accidently" has a lock on an object they
>> don't care two hoots about?
>
>You wait until they release it.  

And if they don't? What if it's an object they've got every right to
hold a lock on for as long as they please?

>If deadlock is detected (you have lock they need, they have lock you
>need) you abort the transaction for one process.

You're worried about putting a little piece of code here and there to
state lock intentions, yet you're willing to pollute every second line
of code with logic to handle what happens in a deadlock situation? I'd
rather put a (set-write-lock) in and predict with certainty what will
happen rather than hope like hell that two objects that I don't expect
will get onto the same hardware page.

Like I said, with page level locking, a deadlock can happen litterally
anywhere. Anytime you call a function or access a variable you've got
a problem. How much fun is it going to be to analyse every single
variable access to decide what you're going to do for a deadlock? What
are you going to do anyway?

People just want to write apps, they don't want to have to deal with
database issues all over the place. One or two tweaks to state lock
intentions people will accept.

>These are all concurrency performance issues, not semantic ones.

No they're semantic issues. Why do you think every RDBMS vendor
(except Sybase) went to row level locking? Not just as a performance
hack I can assure you.

>The waiting and restarting slow you down.  there is never a problem
>for a single processes system.

Sure, but who wants locks on a single process system?