Hi Alex, Should I need to make any code changes for the time being to make it work?
Thanks, Sathish On Wed, Mar 2, 2022 at 3:12 AM Aleksandar Vidakovic < [email protected]> wrote: > Hi Sathish, > > ... work on this has started and parts of the solution are already > available in the "develop" branch. Documentation is still a bit thin > (actually the best at the moment would be to have a look at recent > pull requests... especially those that happened after the 1.6 > release). > > Development towards the next 1.7.0 release has already started and > more improvements along those lines are to be expected... but it will > take some time until we reach the next release. > > The message you pointed to is already a bit dated and some of the > issues are not relevant anymore... most importantly we ditched the > Drizzle driver (actually, the official MySQL driver was always > recommended anyway for production deployments... we just couldn't ship > our releases with it, because of the license incompatibilities); > MariaDD's JDBC driver is now used by default (LGPL is not ideal, but > we can ship). OpenJPA is next on our radar (again, we can't use > Hibernate, because of the licenses involved). > > ... and just to go through your bullet points: > > 1. This is being worked on... whenever something obvious pops up; any > specific improvements via pull requests are highly appreciated... > ideally showing how much of an improvement it would be (tests) > 2. ... not sure if I follow the reasoning here and/or if I have an > opinion about this > 3. ... have to guess here a bit: do you mean the usage of some kind of > retry framework via annotations (e. g. like Resilience4j)? To be > honest, I don't think that this would really help that much. > 4. This is being worked on... the only thing I'm not sure of is if > SavingsAccount was already covered... > > Note: everything that I said is happening in the current develop > branch which is not stable; we try to make everything that lands in > develop as good as we can, but there might be the occasional oversight > or side effect that was not yet tested or didn't appear on anyone's > radar. Another thing you have to keep in mind if you want to test > develop: we've changed the database migration mechanics from Flyway to > Liquibase; if you have a previous database you want to run your tests > on then you have to make sure you used Fineract 1.6 with it first and > then switch to the latest develop code (see also notes in README). > > Hope this helps a little bit... again, pull requests always appreciated. > > Cheers, > > Aleks > > On Tue, Mar 1, 2022 at 7:44 PM Sathish Thangathurai > <[email protected]> wrote: > > > > Dear All, > > > > I have started working on a fineract 1.6 banking solution product. > However, during the testing process we encountered the error as > OptimisticLockException during withdrawal and deposit. Our database has > 10,000 transactions for a single savings account. During testing we > triggered 100 iterations using the POSTMAN rest client. > > > > I'm thinking in the following ways to change the code. > > 1. Using @Transaction with isolation level as serializable so that It > will lock the row > > 2. Using to retrieve latest version of a savings account @Version value > and set that value in the old entity which is going to update in the > database. > > 3. Using @retry to retrieve failed transaction. > > 4. change code from cascade type all to persist in the > SavingsAccount.java for SavingsAccountTransaction mapping. > > > > Any other way to solve this problem? > > > > https://lists.apache.org/thread/2klx9c28jd7rmty7p65qbgs2wmmo25jh. I > followed this link and didn't get clarity on this. > > > > Thanks, > > Sathish > > >
