Jiri Mares radil pouzit tranzakcie, tiez su tu rady, ze datovu
konzistenciu ma drzat databaza, ale co ked "vratenie penazi na ucet
nakupujuceho" je nejake XML volanie do banky. Cize sa to neda spravit
ako nejaka databazova tranzakcia, ani to databaza nemoze riesit svojou
konzistenciou.
No, ono cele je to trochu slozitejsi problem, nez synchronizace - jde o
to nejak nasimulovat distribuovanou transakci (predpokladam ze nemate k
dispozici system s distribuovanymi transakcemi).
Osobne bych to resil tak, ze bych zcela oddelil webove rozhrani a
banovni operace. V operaci stornovani bych jen do zvlastni tabulky
zapsal, ze se ma provest storno:
INSERT INTO bank_operations (id_purchase, operation, time_planned,
time_processed) VALUES (?,'storno',?, NULL)
To by se samozrejme provedlo v jedne transakci s UPDATE ... SET storned
= true;
No a po dokonce by se spustil/naplanoval/probudil/upozornil mel nejaky
task (treba pres JMS, nebo cokoliv) ktery by z te tabulky cetl a
provadel ty jednotlive bankovni operace.
Samozrejme, operace na storno by mela byt synchronizovana primo
vbusiness logice, aby se neprovedla dvakrat; ale v kazdem pripade to
chcipne v databazi na omezeni:
UNIQUE(id_purchase, operation)
To je vse jen takovy nastin co me napadlo. Vyhoda je, ze je v databazi
zaznamenano co se v bance melo provest a co se provedlo a kdy (to je
rozhodne dobry napad) a navic se neceka. Jiste, muze dojit k tomu ze
banka operaci odmitne, ale takove pripady se daji resit postou (v
podstate musi - stejne se bankovni operace neprovadeji v realnem case).
--
Kamil Podlesak <[EMAIL PROTECTED]>
