Daniele Varrazzo ha scritto:
[...]
A me è piaciuta molto la soluzione dei NOTIFY+LISTEN. Ha solo un problema: cosa succede se la transazione finisce ma la cancellazione fallisce?
Questo stato è consistente? Ovviamente dipende dall'applicazione, ma secondo me lo è facilmente. Per esempio in questo stato avresti una foto nell'HD ma nessun record nel DB che dica il nome di quella foto, nessuna pagina che la usa. Forse la foto è raggiungibile comunque via web (es. mettendo a mano una url nel browser, se il file è servito staticamente dal server), ma non ci sono pagine che la linkano... pazienza :) Sarebbe peggio il contrario: una pagina senza foto sarebbe uno stato inconsistente.
Ovviamente a questo puoi affiancare uno script di pulizia, ma solo a scopo di manutenzione, come il vacuum che reclama le tuple inutilizzate.
Se vuoi restare transazionale usando strumenti interni al db puoi usare un commit a due fasi (PREPARE TRANSACTION e amici): solo che ti serve un sistema esterno al db che cancelli l'immagine e che sappia partecipare ad un protocollo di commit a due fasi.
Ma mi sembrerebbe di sparare alle mosche col cannone :)
Insomma, credo che la transazionalità non sia il fine ultimo, ma uno strumento per raggiungere la garanzia della consistenza, che credo sia una proprietà più debole e raggiungibile con altri mezzi.
