| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 36519 |
2 d 13 h |
aman |
/trunk/ |
Fix:First Po |
|
| 36518 |
2 d 13 h |
aman |
/trunk/ |
Fix:Fix first po and edge case for bulk order |
|
| 36502 |
5 d 5 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
DN generation for cancelled MARGINS CNs + fix /A CN prefix extraction NPE
- Add generateDebitNotesForCancelled(List<String>) for explicit CN list
- Add selectByCreditNoteNumbers repository method
- Fix GstProService sandbox: use SANDBOX_GST_NUMBER before isGstEnabled check, sandbox buyer details
- Fix prefix extraction NPE for /A suffixed CN numbers (getCreditNotePdfModel, existingCNMap, extractPrefix) |
|
| 36438 |
12 d 16 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Fix SD Credit over-utilization: use live loan SUM + row lock + sanction guard
- blockLoan: use SELECT FOR UPDATE to prevent concurrent orders from both passing credit check
- processLoanRequest: replace stored utilized_limit counter with live SUM(pending_amount) from loan table
- processLoanRequest + getAvailableAmount: only add sanction amount if not already used today
- Prevents credit limit from going negative due to counter drift or race conditions |
|
| 36372 |
19 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Wallet: SELECT FOR UPDATE on user_wallet mutations to close lost-update hole
addAmountToWallet/consumeAmountFromWallet(x2)/rollbackAmountFromWallet all
follow a read-modify-write pattern on user_wallet with no pessimistic lock
and no @Version, so two concurrent tx for the same partner both read the
same pre-snapshot amount, compute their own deltas, and commit - the second
UPDATE silently overwrites the first's credit/debit. user_wallet_history
still gets both rows, so balance drifts vs sum(history) with no exception.
Replaces the misnamed (and body-broken) selectByIdForUpdate - whose
implementation was a plain selectById, not a lock - with a new
selectByRetailerIdForUpdate that issues SELECT ... FOR UPDATE via
LockModeType.PESSIMISTIC_WRITE, mirroring the idiom already used in
GenericRepositoryImpl.selectByIdForUpdate and OrderRepositoryImpl.
Preserves the create-on-missing behavior of selectByRetailerId so
first-time partners keep working.
Switches the four read-modify-write call sites in WalletServiceImpl from
selectByRetailerId to the new locking variant. Read-only callers
(getUserWalletByUserId, getUserWalletHistoryByUserId, etc.) keep using
the non-locking selectByRetailerId - MVCC snapshot reads stay non-blocking
for display/statement endpoints.
Also drops the stale commented-out selectByIdForUpdate line in
rollbackAmountFromWallet and removes the broken method from the
UserWalletRepository interface / impl - it had zero live callers.
Blast radius: every write call to these three wallet methods now holds
an X-lock on the target user_wallet row for the rest of the outer tx.
Concurrent write tx for the same partner will briefly serialize at the
SELECT FOR UPDATE - correct serialization instead of silent drift.
Read-only traffic is unaffected (MVCC). |
|
| 36371 |
19 d 16 h |
amit |
/trunk/ |
HDFC webhook: INSERT IGNORE on hdfc_payment to fix concurrent-duplicate 500 storm
Replaces persist() with a native INSERT IGNORE so concurrent same-UTR webhook
retries serialize on the unique-index check, and the loser gets a 0-row no-op
(warning, not exception). Outer @Transactional session stays clean, Spring
commits normally, HDFC sees 200 on both the winner (Success) and the loser
(Duplicate) - retry amplification ends.
Flow:
persist(hdfcPayment) -> insertIgnore(hdfcPayment) + selectByUtrNo(utr)
- inserted == 1: proceed with wallet / sidbi side-effects using fetched id
- inserted == 0: respond Duplicate, skip side-effects (owned by winning tx)
- defensive: log warn if insertIgnore returned 0 but selectByUtrNo finds
no row (could mean IGNORE swallowed a non-duplicate issue like truncation)
Also drops HdfcProcessingHelper (r36366) which used REQUIRES_NEW for the same
goal; that approach required a second JDBC connection and is no longer needed
with SQL-level idempotency.
Does NOT touch the wallet-side lost-update hole (user_wallet read-modify-write
without FOR UPDATE). That is a separate commit. |
|
| 36354 |
21 d 12 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
DB-backed concurrent-run guard for OfferBatchService.processOfferWithBatch. Adds CronBatchRepository.selectRunningForOffer(offerId) — single HQL query for RUNNING cron_batch rows named processSellinOffer-N or processActivationOffer-N. OfferBatchService early-returns (with a log) if any such row exists. Covers the three gaps the in-memory guard can't: JVM restart, multi-JVM, cron CLI + user click racing. Applies to both sync (cron --processOffersWithBatch) and async (/offer/process HTTP) paths. |
|
| 36351 |
21 d 13 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Add CronBatchRepository.selectRecent(limit) and CronBatchItemRepository.selectByBatchId(batchId) for admin batch review UI. selectRecent returns most-recent-first via selectAllOrderByDescPaginated('id'); selectByBatchId uses selectAllByEqualOrderByDesc. |
|
| 36330 |
22 d 12 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Fix getWarehousewiseCollection: add timestamp index, drop misleading FORCE INDEX
EXPLAIN on hadb1 showed the query was full-scanning transaction.userwallethistory
(1.9M rows) despite FORCE INDEX (idx_uwh_wallet_timestamp). The composite
(wallet_id, timestamp) needs an equality predicate on wallet_id to be usable,
but this query filters by uwh.timestamp at the scan level with no wallet_id —
driven from fofo_store via joins. Optimizer correctly rejected the hint and
picked ALL. Query averaged 773 ms across 4,095 calls (3,167 s cumulative).
- add_idx_uwh_timestamp_reftype.sql: new index on (timestamp, reference_type)
so the range scan narrows by time and reference_type filters inline.
- UserWalletRepositoryImpl:110: drop FORCE INDEX hint; let optimizer choose.
Updated comment to explain why.
Left PartnerCollectionPlanRepositoryImpl.getCommitmentCollectionSummary:117
untouched — that query drives from pcp → userwallet → userwallethistory and
the join has wallet_id = uw.id known at scan, so (wallet_id, timestamp) is
the right index there; FORCE INDEX remains appropriate. |
|
| 36328 |
22 d 13 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Remove @Cacheable from getFirstBillingDate — LocalDateTime + Redis incompatibility
The redisOneDayCacheManager (CacheConfig.java:109-116) is configured with
enableDefaultTyping(NON_FINAL, JsonTypeInfo.As.PROPERTY). That embeds type info
as a JSON object property, which is only valid for objects ({}) — not arrays.
JavaTimeModule serializes LocalDateTime as an array ([y,m,d,h,m,s]), so the
write drops type metadata and reads fail with MismatchedInputException
('need JSON String that contains type id').
The underlying NamedQuery (Order.selectFirstBillingByRetailer) uses MIN() on
the idx_order_customer_billing composite index — EXPLAIN reports 'Select tables
optimized away'. Per-call latency is microseconds even uncached, so Redis
caching was optimization rather than requirement. Simpler to drop the annotation
than reconfigure the shared cache manager. |
|
| 36327 |
22 d 14 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Fix currentinventorysnapshot/currentreservationsnapshot deadlock and optimize getFirstBillingDate
- SaholicInventoryServiceImpl: enforce reservation-snapshot → inventory-snapshot
lock order in addReservationCount and reduceReservationCount via explicit
session.flush(); eliminates the hadb1 deadlock recorded 2026-04-20 19:43:24
between these two methods' opposite-order writes.
- SaholicInventorySnapshot: add @DynamicUpdate so UPDATEs only rewrite the
changed column instead of all three — cuts redo/binlog write amplification
and makes deadlock dumps pinpoint the actual business path.
- TransactionRepositoryImpl.getFirstBillingDate: replace filesort-over-all-billed-
orders with MIN(billingTimestamp) via new Order.selectFirstBillingByRetailer
named query (Select tables optimized away). Preserves 2017-01-01 cutoff and
null-for-unbilled-partner semantics.
- Add @Cacheable on redisOneDayCacheManager keyed by fofoId (unless null) so the
8 call sites stop piling up identical SELECTs on the order table — this was
the query pinning Hikari slots at 150-460s each in recent processlist dumps. |
|
| 36305 |
24 d 20 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Batch processing infrastructure + per-partner offer processing + partner limit optimization + investment cache eviction on billing/payment/cancellation with 3hr TTL |
|
| 36296 |
26 d 12 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Add 2-min cache on dashboard-family queries
Three queries dominate dashboard DB time (~830 s / 30 min combined) because
they re-execute on every dashboard refresh with near-identical parameters:
- OrderRepositoryImpl.selectPartnersBilledBetweenDates: dynamic endDate is
LocalDateTime.now(), so cache key bucketed to 2-minute boundaries via SpEL
(endDate.toEpochSecond / 120) so calls in the same bucket share an entry.
- UserWalletRepositoryImpl.getPartnerWiseCollectionAchievement and
RbmTargetServiceImpl.getWeeklyBillingDataForMonth: default Spring key
(fofoIds + startDate) is stable, no bucketing needed.
All three use the existing Caffeine 'twoMintimeoutCacheManager' (in-memory,
per-JVM, expireAfterWrite=2min). unless clause skips caching empty results
so legitimately-empty responses don't pin a bad entry. |
|
| 36294 |
26 d 14 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Remove @Cacheable from getFirstBillingDate
Temporary revert while cache null-handling is reviewed end-to-end.
The method returns null for partners with no billing history; the
Redis cache (disableCachingNullValues) was causing log noise even
after unless="#result == null" was added. Reverting to direct DB
lookup until a proper caching strategy (e.g. per-cache nulls or
Optional return type) is decided. |
|
| 36293 |
26 d 14 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Fix IllegalArgumentException when caching null firstBillingDate
Redis cache manager (redisEternalCacheManager) has disableCachingNullValues,
so every partner with no billing history threw IllegalArgumentException
from RedisCache.put. Added unless="#result == null" to skip cache writes
for null results; non-null results still cache normally. |
|
| 36291 |
26 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/ |
Optimize slow DB queries: split fan-out join, FORCE INDEX on wallet history
- CurrentInventorySnapshotRepositoryImpl.getSpilitStockBatch: split
LEFT-JOIN fan-out into two independent aggregates (~8x faster);
fixes SUM(DISTINCT) undercounting bug where same availability/qty
values across items collapsed into one.
- UserWalletRepositoryImpl.getWarehousewiseCollection: HQL -> native
SQL with FORCE INDEX(idx_uwh_wallet_timestamp) so timestamp range
filters at index level instead of row filter (~4x faster, 3.1s -> 722ms).
- PartnerCollectionPlanRepositoryImpl.getCommitmentCollectionSummary:
Criteria 3-Root CROSS JOIN -> explicit INNER JOIN + FORCE INDEX
(idx_uwh_wallet_timestamp) (~3.5x faster). |
|
| 36288 |
26 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
hadb1 perf: cache firstBillingDate, fix N+1 item query, push eInvoice filter to SQL, sort updateRisk by fofoId |
|
| 36218 |
35 d 16 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Credit/Debit note enhancements: add margin_month + cancelled columns, fofo_dn_sequence on sellerwarehouse, generateDebitNoteIrn for margin reversals, selectCancelledByMonth repo, generateDebitNotesForCancelled service, cn_date = ack_date, dedup by margin_month, source-based descriptions (Schemes/Offers vs Price Drop), skip negative margin line items for CRNs |
|
| 36008 |
57 d 8 h |
aman |
/trunk/ |
Fix:Redesign the Po Approval page add total count, Add mail in bcc for testing , partnerpending task api response optimisation, |
|
| 35997 |
60 d 8 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Invoice Return: PurchaseReturnOrder entity, ReturnAction DAO enum, receive/refund/reject service, ReturnOrderInfo selectByOrderId |
|