Buongiorno a tutti.

Da una tabella ordini ricavo l'ultimo numero ordine per assegnarlo all'ordine successivo quando l'utente apre un ordine.

Siccome gli utenti sono tanti succede (raramente ma succede) che più utenti richiedono un numero d'ordine nello stesso istante.

Si generà cosi un DEADLOCK perchè la tabella ORDINI è bloccata dalla transazione che apre il primo richiedente (il che è cosa buona e giusta ovviamente).

Il problema è che gli altri utenti vengono "buttati" fuori e devono riprendere da capo a fare l'ordine (il che è un problema... lamentele varie e via dicendo).

Mi chiedevo come fosse possibile gestire (non evitare perchè è ovviamente impossibile) il DEADLOCK in modo che posso fare aprire più ordini contemporaneamente e ricavare il numero ordine successivo senza incorrrere nel DEAD LOCK.

Immagino che (ad es.) AMAZON abbia problemi del genere avendo milioni di clienti e lo abbia gestito.

Ho cercato "in giro" Non sono riuscito a trovare una soluzione (o workaround).

Grazie a chiunque mi possa fornire qualche indicazione.

Filippo Quaranta

salve Filippo,
tendenzialmente non mi pare una soluzione geniale assegnare il numero d'ordine al momento dell'apertura del carrello...
il carrello puo' restare potenzialmente "appeso" a lungo, e ovviamente addirittura non essere neanche confermato, quindi senza arrivare al cosidetto check-out...

detto cio', senza necessita' che corrisponda a realta', personalmente non utilizzerei in questo senso un "numero", cioe' un progressivo ordinale nel dominio numerico degli interi, ma ad esempio utilizzerei un guid generato lato server e passato al carrello...
se proprio poi ti serve un valore nel dominio numerico, al momento della conferma d'ordine provvederei a gestirne la costruzione, utilizzando anche eventualmente un'identity (che pero' potrebbe presentare dei gap) o, proprio nella peggiore delle ipotesi, calcolando il "cosidetto" max +1, ma solo al momento della conferma dell'ordine, che tendenzialmente e' un'operazione atomica che deve essere molto breve e veloce, non bloccante per altri processi, se non per la verifica di presenza e disponibilita' dei prodotti...

scrivi:
>Si generà cosi un DEADLOCK perchè la tabella ORDINI è bloccata dalla transazione che apre il primo richiedente (il che è cosa buona e giusta ovviamente).

veramente NON e' una cosa buona e giusta... a mio avviso, la tabella NON dovrebbe essere lockata... cosa devono essere "in qualche modo lockati", sono i prodotti, nel senso che non puoi vendere qualche cosa di cui tu non abbia la disponibilita'... in questo senso il modus operandi dei voli e' "funzionale"... il posto e' libero sino al momento del commit della tua operazione di prenotazione... tu "gingilli" con il tuo posto e, al momento di premere il bottone di conferma, ti viene prenotato il posto se (ancora) disponibile oppure ti viene notificata l'indisponibilita' di quanto richiesto... anche a mio parere cosi' deve funzionare, lasciando "vendibile" il prodotto per il primo che chiuda il carrello e non bloccando la vendita a potenziali clienti mentre l'utente e' andato magari a mangiare lasciando "aperta" la maschera del carrello. E vorrei pensare che tendenzialmente tutti i siti di e-commerce operino in tal senso.

salutoni romagnoli
--
Andrea

---

Modificato da Andrea Montanari il 19 aprile 2021 21:49 -

Ciao...

Scusa ho scritto una fesseria.

Il numero lo genero quando chiudo l'ordine.

Ciao laurar181.

Faccio il MAX + 1 perchè il requisito è quello di avere ordini numerati da 1 in progressione senza interruzioni numeriche (come fosse una fattura).

Ma per avere il numero successivo devo avere prima "salvato" l'ordine precedente.

Per cui se 3 utenti concorrenti fanno la richiesta 2 potrebbero (è questione di millesimi di secondo) incorrere nel DEAD LOCK della precedente transazione in corso sull'ordine in inserimento.

Da qui il mio (potenziale) problema.

Filippo