[
https://issues.apache.org/jira/browse/FINERACT-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17941820#comment-17941820
]
Piotr Wargulak commented on FINERACT-2234:
------------------------------------------
Hello [~adamsaghy], I'm a developer from SolDevelo (see the "How to help with
Fineract performance" mailing list thread), and I would like to look into this
issue.
_(I'm not able to assign myself)_
I've started looking into the code around the Loan COB Job and saw your
[email|https://lists.apache.org/thread/xf88or8s4p307mdqoosth1lsorchm4pb] from
yesterday.
Based on code review, I have a couple of findings (see below). I didn't look at
Business Steps implementations very much yet.
I plan to learn the code a little bit more, and then prepare some test data to
measure the current performance and have a baseline to compare what and if any,
modifications are improving it.
I will probably try some changes around the code review findings, and some
things that may come up, after I am able to see the job running on my machine.
h3. Code review findings
# The `AbstractLoanItemReader.read` reads the Loan entity one-by-one, when a
natural approach would be to read the whole chunk to save on DB trips.
Although, I'm aware of the Loan entity having so, maybe it was a conscious
decision.
# The Loan entity is heavy - as already mentioned
[here|https://lists.apache.org/thread/xf88or8s4p307mdqoosth1lsorchm4pb]. A good
approach would be to make every relation fetched Lazy. Although, I see that
`LoanAssembler` is loading all collections explicitly, and I wonder if there is
any code that uses Loan entity outside JPA context (risking
LazyInitializationException when leaving collections not-loaded).
# The `LoanRepository` has many queries that return lists of `Loan`, and none
of them utilize EntityGraphs to work around the N+1 problem. The Loan entity,
being heavy itself, might benefit from
[EntityGraphs|https://jakarta.ee/learn/docs/jakartaee-tutorial/current/persist/persistence-entitygraphs/persistence-entitygraphs.html]
in general (fetch only data that is needed for specific business logic).
# There is something strange going around the `LoanItemReader` ->
`LoanItemProcessor` -> `LoanItemWriter` logic that feels off. It operates on
the managed entity, which is loaded by `LoanItemReader`, then it's reloaded by
`ReloaderService` for each Business Step of `LoanItemProcessor`, modified by
Business Step implementation (since it's managed, changes will be reflected in
DB unless rollback), and then fake saved in `LoanItemWriter` - fake because
there are no new Loans created, and all objects are managed. I don't think
there is any specific performance impact - I assume entity reload will read the
entity from JPA context - but I wonder if the better approach would be to
operate on some unmanaged data object.
I've also found that in some cases, the result of `LoanItemReader` is cached,
leading to a detached entity being possibly used in the processor - the
`ReloaderService` looks like the fix for it.
> Loan COB (Close of business day) performance improvements
> ---------------------------------------------------------
>
> Key: FINERACT-2234
> URL: https://issues.apache.org/jira/browse/FINERACT-2234
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Adam Saghy
> Priority: Major
>
> This story is aiming to review, analyse and improve the performance of the
> Loan COB job, including its business steps!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
