E' vero che la cosa viene ridotta, ma non eliminata; la casualità è sempre in agguato.
Come ha descritto leo, anticamente si usava un simile accorgimento, però sul database stesso, approntando opportunamente una tabella di numeri fattura prenotati. Anche questo approccio, però, aveva dei problemi, legati al fatto che un operatore poteva annullare la fattura che stava compilando, creando così dei buchi, che tra le altre cose non erano molto legali; diciamo che andavano a finire come fatture annullate.
Con un'approccio odierno è possibile, utilizzando ad esempio una sequence, far inserire il numero automaticamente dal motore del db, in fase di inserimento; però questo comunque implica sia un problema simile a quanto scritto sopra, sia un controllo di contemporaneità da parte del motore db. Quest'ultima cosa è sicuramente espletata dai database moderni, su sqlite non sò...
A parte l'ipotesi di gestire fatture, se non esistono problemi di mantenere una numerazione costante e senza buchi, l'approccio di cui sopra, ovvero la prenotazione dei numeri, può essere un'ipotesi trattabile, e anche abbastanza semplice da realizzare (basta una tabella e poco codice...).
Per l'approccio della modalità EXCLUSIVE avrei dei dubbi, legati più al fatto di gestire nel più breve tempo possibile il locking, altrimenti non lavora più nessuno. Su DB3, ad esempio, si usava un piccolo loop a tempo che analizzava la possibilità di modificare un record, e se entro il tempo previsto ci riusciva bene, altrimenti avvertiva l'utente che l'operazione non era possibile, proponendo un siccessivo tentativo.
