asmhatre
b4a623b889
Separate write/read DataSources, a JPA command side, and two interchangeable projection listeners (sync and @Async) demonstrating the real latency-versus- freshness trade-off CQRS forces. Includes a reflection-based proof that the query side has no dependency on the write side, and a real failure/fix transcript for the -parameters compiler flag this standalone reactor doesn't inherit from spring-boot-starter-parent.
21 lines
1.6 KiB
Plaintext
21 lines
1.6 KiB
Plaintext
$ mvn -pl cqrs test -Dtest=SyncProfileLatencyTest
|
|
(default profile -- SyncOrderSummaryProjection active; its write to order_summary runs
|
|
on the same thread that is about to answer the command's HTTP request)
|
|
|
|
2026-10-04T02:27:21.596+05:30 INFO 17202 --- [cqrs] [ main] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Added connection conn0: url=jdbc:h2:mem:cqrs-write user=SA
|
|
2026-10-04T02:27:22.729+05:30 INFO 17202 --- [cqrs] [ main] com.zaxxer.hikari.pool.HikariPool : HikariPool-2 - Added connection conn10: url=jdbc:h2:mem:cqrs-read user=SA
|
|
|
|
POST /orders (sync profile) took 670 ms, orderId=9ee5b016-7a81-40f9-8d7a-d7d1959c09be
|
|
Immediately after POST returned, GET /order-summaries/9ee5b016-7a81-40f9-8d7a-d7d1959c09be -> status=200 OK, body=OrderSummary[orderId=9ee5b016-7a81-40f9-8d7a-d7d1959c09be, customerName=Priya, itemCount=2, totalCents=7597, status=PLACED, updatedAt=2026-10-03T20:57:24.283700Z]
|
|
|
|
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
|
|
|
|
Two real HikariCP pools, one per DataSource bean -- that line alone is a cheap way to
|
|
confirm the write and read sides really are two separate connection pools to two separate
|
|
H2 databases, not one database with two tables. The 670ms includes the 300ms the projection's
|
|
simulated write delay adds on top of real JPA/Hibernate first-request costs (see
|
|
output/01-async-profile-staleness-window.txt's warm-up note for what that baseline actually
|
|
is) -- and because that write finished before the HTTP response did, the very next GET
|
|
against the read model, with no wait at all, already sees itemCount, totalCents and status
|
|
correctly populated.
|