Subversion Repositories SmartDukaan

Rev

Hide changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff Changes
37588 26 d 9 h amit /trunk/profitmandi-dao/src/main/ Serve partner investment from a 2-minute snapshot instead of a 3-hour cache

getInvestment() was @Cacheable on a 3-hour Redis cache that addAmountToWallet
evicted but consumeAmountFromWallet did not. A partner whose advance payment was
swept straight to a loan had the money counted twice - once as a still-cached
wallet balance, once as the reduced utilisation - overstating their credit limit
by the payment x their tier until the cache expired.

Replaced with fofo.partner_investment, refreshed every 2 minutes by
PartnerInvestmentSweepService. Every coupled term is read in one pass, so wallet
and utilisation (and in-stock and aged-Apple) can never come from different
moments. A shorter TTL would only have made the error rarer - it scales with the
payment, not the delay.

- PartnerInvestment entity/repository + partner_investment_snapshot.sql
- PartnerInvestmentSweepService: 9 batched reads, stores base_value for change
detection, refreshes aged-Apple for partners whose stock moved intra-day
- getInvestment/getInvestmentsForFofoStores both read the snapshot, so the two
paths no longer disagree; live compute retained as fallback
- selectActivatedStockAmountByFofoIds: batches an N+1 that cost 233ms x 1690
partners (6.6 min -> 1.0 s)
- getFirstBillingDates: batches another N+1 (4.6 s -> 0.67 s)
- selectPendingGrnOrders(List) now applies the same SD_START_DATE floor as the
single-partner overload; the two were reporting different GRN-pending
- selectPartnerStockValueMap takes excludeActivated: an activated Apple handset
held past the aging window was added once to in-stock and subtracted twice
(activated stock, then the aged haircut). 90 units, 24 partners, Rs 65.19 lakh
double-deducted. Live-demo passes false - no overlap there.
- applyManualAdjustment: routes the two hand-rolled admin wallet adjustments
through WalletServiceImpl so they take the FOR UPDATE lock
- add_idx_order_grn_pending.sql: covering index, GRN query 1320ms -> 514ms
 
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerInvestment.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PartnerInvestmentRepository.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PartnerInvestmentRepositoryImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentSweepService.java
/trunk/profitmandi-dao/src/main/resources/sql/add_idx_order_grn_pending.sql
/trunk/profitmandi-dao/src/main/resources/sql/partner_investment_snapshot.sql
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/InventoryItem.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/Order.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepository.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepositoryImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/TransactionRepository.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/TransactionRepositoryImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentServiceImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/wallet/WalletService.java
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/wallet/WalletServiceImpl.java