Woody,

>I agree with this type of solution, however, reading data isn't really an
>issue, only modifying it, except in specific cases.

Yes of course writing is the problem, but if the application
locks the record before presenting data to the user, it avoids
making the user rethink his problem. You're quite right also
when you point out that this particular issue, updating a counter,
doesn't require any real subtlety. I don't understand what
Danny means when he says:

> I think too that generator is not a good option because the
> counters would be consecutive 1,2,3,4,5.

Generators are generally consecutive, though you could choose
to implement a random increment generator. If the problem is
the other way around - that an abandoned transaction would leave
a hole in the sequence (1,2,whoops!,4,5), that's a potential
problem for almost any solution except one that actually serializes
updates, or in this case, inserts.

>Too many times I've seen
>posts that say something like "My app hangs until the other user releases
>their transaction."

As you've said, once you've updated your records, end the
transaction! That problem occurs only because someone has
been lazy about closing transactions.

>Using wait transactions can cause just as serious a
>problem for some applications as using no-wait transactions. It's all in
>what you are trying to do. What works best in one situation may not work in
>others. DIfferent situations require different and sometimes unique
>solutions.

Fair enough... I'm something of a fanatic on concurrency
and consistency. Maybe for a beginner doing baby applications,
serialized transactions that alter only one record each are ok.
[Calm yourself Ann... crawl back into your cave.]

Anyway, if I were Danny, I'd use a generator and get out of
this whole discussion.



Regards,

Ann
www.ibphoenix.com
We have answers.