Hi Dennis,
> > The way make sure that you have no deadlock problems is to
> > ensure that it's
> > never called from inside a transaction.
>
> And if you don't have a transaction ... you end up with missing numbers,
> partial orders, and worse still, more deadlocks. This is because
Yes, you can end up with missing numbers. I don't think that's an issue if
you're generating unique row identifiers, but it might be a problem if
you're generating "Order Numbers", for example.
Can you explain the "partial orders" problems that you see here?
> > SQl.Add('update incrementTable
> > set nextValue = :newValue
> > where keyid = :keyid
> > and nextValue = :originalValue');
>
> causes the server to generate an implicit transaction - one which you have
> no control over.
I'm pretty sure that a transaction which consists of an update to a single
row can't cause a deadlock. Can it? I have 'no control' over the implicit
transaction, it's true, but what sort of control *might* I want?
> It is also slower because you generate two transactions instead of one;
one
> for the update and another for the new order insert.
Well, yes, but it's hardly going to be a major performance bottle-neck now
is it? :-)
> If you add another field to the number generation table, and use that as a
> synchronisation point to serialise inserts/updates to orders, it makes it
> impossible to deadlock, thought the real solution to deadlocking is to
> design your inserts/updates so that they DONT deadlock.
I find it easier to use techniques that just work, and don't rely on people
to design things properly. That's just being to darn optimistic, especially
in a large development team.
Cheers,
Kerry Sainsbury
Inprise/Borland New Zealand
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
