1. yes 2. yes > interpret your comment to be about the standard issue of not getting these side effects again during disaster recovery. Correctly understood? yes
To sum it up - there is a problem (how to recover from a disaster) that is currently not solved in Fineract but I think it should be. I created a JIRA ticket for it as well: https://issues.apache.org/jira/browse/FINCN-187 Anyone is welcome to update the ticket. Juhan Kontakt Niklas Uhrberg (<niklas.uhrb...@resurs.se>) kirjutas kuupäeval R, 25. oktoober 2019 kell 13:46: > Juhan, just so that I interpret you correctly in > > "The current problem however is that there are some commands that when > they get executed, > they create other commands as a result (when you replay such a command you > will create a command again - although it exists already)" > > These "other commands" can be either of two types: > 1. Commands that just lead to further state changes in the database and > that these changes do not lead to other side effects. (The state of which > we wish to restore after a disaster) > 2. Commands that not only lead to state changes in the data base, or state > changes that lead to side effetcts. Examples : Email sent to customer, > calls to other services that mutate state. > > I interpret your comment to be about the standard issue of not getting > these side effects again during disaster recovery. Correctly understood? > > > I just want to point to the fact that in an event sourced system this > problem goes away since the events that are replayed only serve the purpose > of building up the application state . > > > Best regards Niklas > > > > > Niklas Uhrberg > Konsult > IT Development | Loans & Credit > > > > Resurs Bank AB > > > > Växel: +46 42 38 20 00 > E-post: niklas.uhrb...@resurs.se > Webb: www.resursbank.se > > > > ------------------------------ > *From:* Juhan Aasaru [aas...@gmail.com] > *Sent:* Thursday, October 24, 2019 6:43 PM > *To:* Victor Romero > *Cc:* Dev; Niklas Uhrberg > *Subject:* Re: Usage of Cassandra in Fineract CN > > Hi! > > I just recently learned that this design would also help on recovering > from a disaster. > > Cassandra can be easily replicated so the risk of loosing all the > Cassandra nodes is relatively small. > And even if that happens you only loose the commands that are not executed > yet (not a huge problem > since any command could fail after it is issued). > > Postgres can also be replicated but at one point the database (and > replica) could become corrupt. > So you restore it from the recent backup but you face the problem that the > backup is probably at least several hours old. > To solve the issue you could replay the commands in Cassandra to bring the > database restored fromt the backup to the lasest state. > > The current problem however is that there are some commands that when they > get executed, > they create other commands as a result (when you replay such a command you > will create a command again - although it exists already) > So there should be a mechanism in place in Fineract-CN to identify such > commands so one could skip executing them during replay > (or some other stattegy to deal with this). > > Juhan > > > Kontakt Victor Romero (<victor.rom...@fintecheando.mx>) kirjutas > kuupäeval N, 24. oktoober 2019 kell 17:28: > >> Yes it is. >> >> >> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+Project+Structure#FineractCNProjectStructure-cassandra >> >> El 24 de octubre de 2019 a las 08:11 AM Niklas Uhrberg < >> niklas.uhrb...@resurs.se> escribió: >> >> >> Hi! >> >> I didn't pay much attention to the Cassandra database when looking at >> Fineract CN, but now I read >> https://cwiki.apache.org/confluence/display/FINERACT/CQRS+in+Fineract+CN >> and I conclude from this documentation that the only usage of Cassandra is >> to persist the commands. >> >> Furthermore that one and the same database is used in the processing of >> the commands , i.e. the state changes in the Postgres db as a consequence >> of a command being processed occur in the same Postgres database used to >> serve read style requests (since there is only one Postgres db) >> >> Is this correctly understood? >> >> Best regards Niklas >> >> >> >> >> Niklas Uhrberg >> Konsult >> IT Development | Loans & Credit >> >> >> >> >> Resurs Bank AB >> >> >> >> >> Växel: +46 42 38 20 00 >> E-post: niklas.uhrb...@resurs.se >> Webb: www.resursbank.se >> >> >> >> >> >> >> >
