<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 1 ottobre 2015 13:32, Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Il giorno 30 set 2015, alle ore 22:24, Marco Paolini <<a href="mailto:markopaolini@gmail.com">markopaolini@gmail.com</a>> ha scritto:<br>
><br>
> Se product e Payment fossero in due microservice differenti, dovremmo creare una transazione distrubita (XA) e gestire il fallimento a livello applicativo. Molto + codice, molto + difficile da testare.<br>
><br>
><br>
<br>
</span>Curiosità da parte di qualcuno con tanta 'pratica e poca teoria alle spalle:<br>
<br>
In una situazione come quella che proponi il mio primo approccio sarebbe quello<br>
di avere un unico servizio che mette in una coda un identificativo temporale univoco<br>
con le operazioni da compiere e successivamente uno o più servizi prendono l'evento<br>
e ciascuno per la sua parte compie le operazioni necessarie.<br>
<br>
Capisco che è un approccio 'naif' ma non consentirebbe appunto di segmentare un<br>
applicativo monolitico salvando le logica delle transazioni ?<br>
<br>
Se una transazione fallisce dovrebbe essere possibile effettuare una sorta di rollback<br>
dell'intera transazione proprio perchè esiste un luogo dove è presente in nuce<br>
l'intera transazione anche se non ancora attualizzata nelle scritture necessarie<br>
nei singoli servizi.<br>
<br>
Insomma un po' i WAL di postgres ma nell'ottica di servizi distribuiti.<br></blockquote><div><br></div><div>Si, è così che si fa (credo) cioè con un repository centrale (etcd, zookeper, postgres stesso) che si occupa di tener traccia delle transazioni distribuite.</div><div><br></div><div>Io credo che questo approccio sia più complesso da implemetare rispetto a: BEGIN; SELECT FOR UPDATE; COMMIT . Credo anche che quando il progetto diventa molto grande, magari conviene implementarlo anche se è più complesso. Non ho molta esperienza in proposito.</div><div><br></div><div>Ciao</div></div></div></div>