[Db] contatore server side

[Marcello Vezzelli]

Domenico L. wrote:
>
>> Ma fare una lock table in questi casi serve a qualcosa o è una 
>> bestialità?
> No mysql 5 ha il lock a livello di riga quindi tutto bene.


>
> Mi lascia un po' da pensare il concetto che è possibile cancellare 
> l'ultima, in un ambiente concorrente il concetto di ultima è una cosa 
> che non ci si può permettere di avere.

Supponiamo che la transazione che si occupa di cancellare l'ultima 
fattura faccia una lock table... consideriamo la cancellazione 
dell'ultima fattura un evento raro e va bene gestirlo in questo modo.

Se qualcuno posta durante la cancellazione, si becca un errore del tipo 
"table locked" e fa il rollback. Corretto?
Gestendo la cosa lato applicativo, si aspetta un attimino e si riprova. 
Parliamo veramente di centesimi di secondo, ma la questione è 
concettuale quindi vale la pena discuterne... supponiamo che la 
cancellazione di un record duri un tempo lungo a sufficienza.
Finita la transazione della cancellazione, il nuovo post otterrà 
correttamente il valore numfatt facendo una select dell'ultimo numero di 
fattura in tabella incrementato di uno.
Domandone: da quanto ho letto, l'esecuzione del trigger BEFORE INSERT è 
atomica su ogni tabella, corretto? Ovvero il trigger gira fuori da 
qualsiasi transazione, quindi sono tutti sequenziali.
>
> Anche perché potrebbe diventare l'ultima di un utente... ma qui stiamo 
> di fatto introducendo una soluzione (peraltro già vista in software di 
> fatturazione) che le fatture vengono inserite e successivamente (dopo 
> x giorni o manualemente) convalidate, quindi gli si assegna il numero.
>
> Ora se loro vogliono questo, ferma tutto, perché l'approccio è ben 
> diverso, altrimenti dopo proseguo ;-)

Ma non si sposta il problema e basta? Se dopo che l'ho convalidata la 
voglio cancellare siamo da capo...
E' come dire che la vita sulla Terra veniva da Marte. E quella su Marte? :D

Ciao
Marcello