[prev in list] [next in list] [prev in thread] [next in thread]
List: mifos-functional
Subject: [Mifos-functional] status of Redo Loan Dispersal
From: "Tom Bostelmann" <tbostelmann () gmail ! com>
Date: 2007-07-26 6:40:34
Message-ID: dca7158e0707252340m7bc15a9bx66b2f952a0e8f255 () mail ! gmail ! com
[Download RAW message or body]
I'm giving an update a little early because several issues have come up
recently that are impacting completion time (I'll give another status at the
end of the week as well).
1.) Transaction management problems are going to force substantial
refactoring.
Problem: Each of the following steps as written in the code calls a commit
to the database. All of them are required in order to 'redo a loan':
- Creating a Loan in the past (twice)
- Approving the Loan
- Disbursing the Loan
- Applying payments (one commit per payment)
If any one of these steps fail, you can only rollback to the previous step.
So data integrity is a problem.
The only other place I could see multiple task processing like this is in
the bulk entry code code where it gets around our Thread-scoped transactions
by spawning new threads in order to process the work.
Solution: I'm going to have to create new implementations of these methods
and related tests. The new implementations will be implemented in the
Service level (as discussed in a previous design-related email with
Jim/Van).
Transaction management needs to be separated. The strategy here should be
that a transaction is started at the beginning of a request and committed at
the end. So the Transaction solution needs to integrate with the UI layer (
i.e. HTTP Request/Response).
Estimated Additional Effort: ~ 3-5 days.
2.) Related issue: generating and storing Global Account Numbers/ID's
requires two transactions.
The task of creating a loan is done in two transactions at this point. The
fist transaction creates the loan in order to generate it's id. The second
transaction then creates the GlobalAccountNumber using this id and the
Global ID of the creator's Branch Office. It appears that most, if now all,
Global AccountNumber/ID's are generated this way.
The likelihood of a failure occurring between these two transactions is
pretty low. In the 'redo loan' case, though, it becomes more likely that a
loan will end up being created and committed to the database with a random
portion of the remaining tasks completed (depending on the outcome of
lower-level validation and potential runtime errors).
Solution: Have the database generate this value when it inserts the record.
Factors:
- There may be additional code that relies on the immediate generation of
the loan ID and GlobalAccountNumber - requiring further refactoring.
Estimated Additional Effort: It's difficult to say since I haven't verified
that the solution will work.
3.) Low-Priority Issue: Evidence of lazy initialization in Loans not working
(see EdotStatisAction.update()).
Unfortunately the hack that's in place is to fill in the attributes with
contextual data. I should be identical data, though - but this has the
potential to create very complicated bugs.
Solution: Still needs to be investigated.
[Attachment #3 (text/html)]
I'm giving an update a little early because several issues have come up recently \
that are impacting completion time (I'll give another status at the end of the \
week as well).<br><br>1.) Transaction management problems are going to force \
substantial refactoring. <br><br>Problem: Each of the following steps as written in \
the code calls a commit to the database. All of them are required in order to \
'redo a loan':<br><br> - Creating a Loan in the past (twice)<br> - \
Approving the Loan <br> - Disbursing the Loan<br> - Applying payments (one \
commit per payment)<br><br>If any one of these steps fail, you can only rollback to \
the previous step. So data integrity is a problem.<br><br>The only other place \
I could see multiple task processing like this is in the bulk entry code code where \
it gets around our Thread-scoped transactions by spawning new threads in order to \
process the work. <br><br>Solution: I'm going to have to create new \
implementations of these methods and related tests. The new implementations \
will be implemented in the Service level (as discussed in a previous design-related \
email with Jim/Van). <br><br>Transaction management needs to be \
separated. The strategy here should be that a transaction is started at the \
beginning of a request and committed at the end. So the Transaction solution \
needs to integrate with the UI layer ( i.e. HTTP Request/Response).<br><br>Estimated \
Additional Effort: ~ 3-5 days.<br><br><br>2.) Related issue: generating and storing \
Global Account Numbers/ID's requires two transactions. <br><br>The task of \
creating a loan is done in two transactions at this point. The fist transaction \
creates the loan in order to generate it's id. The second transaction then \
creates the GlobalAccountNumber using this id and the Global ID of the creator's \
Branch Office. It appears that most, if now all, Global AccountNumber/ID's \
are generated this way. <br><br>The likelihood of a failure occurring between these \
two transactions is pretty low. In the 'redo loan' case, though, it \
becomes more likely that a loan will end up being created and committed to the \
database with a random portion of the remaining tasks completed (depending on the \
outcome of lower-level validation and potential runtime errors). <br><br>Solution: \
Have the database generate this value when it inserts the record.<br><br>Factors: \
<br>- There may be additional code that relies on the immediate generation of the \
loan ID and GlobalAccountNumber - requiring further refactoring. <br><br>Estimated \
Additional Effort: It's difficult to say since I haven't verified that the \
solution will work.<br><br><br>3.) Low-Priority Issue: Evidence of lazy \
initialization in Loans not working (see EdotStatisAction.update ()). \
<br><br>Unfortunately the hack that's in place is to fill in the attributes with \
contextual data. I should be identical data, though - but this has the \
potential to create very complicated bugs.<br><br>Solution: Still needs to be \
investigated. <br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic