[ningmao-hlyz]

AgentScope-Java Version

2.1.0-SNAPSHOT (main)

Description

Reported in #3612，#3647 : listing the sessions of a user with 17 sessions of a few thousand events

took over 6s on Windows.

Core issue: connection setup overhead during replay. In the original implementation on main, every storage.read call opens a new JDBC connection and executes a table-creation DDL statement. Replay traverses the commit chain segment by segment, reading each segment twice. With 17 sessions × 3,000 events, this results in over 20,000 connection setups, which accounts for the 12.6-second runtime. After switching to batch reads, the entire replay requires only two connections—one for listPaths and one for readAll—bringing the measured runtime down to 1.6 seconds.

Additional benefits: All code paths that use scan benefit as well, including getAgentState, session restoration, and session search.

Changes

• AtomicSessionStorage gains a readAll(paths) default that falls back to per-path reads.
  SqliteSessionStorage overrides it to serve the whole batch over one connection.
• JournalSessionLog.scan bulk-loads every committed segment up front (one listPaths + one
  readAll — two round-trips per journal replay instead of two per segment) and walks the hash
  chain in memory. The chain checks (cycle detection, contiguity, checksum) are unchanged; they
  just run over in-memory data. Payload blobs are still hydrated per read. The listing surfaces
  physically-present rows — including segments a concurrent writer has not yet referenced from
  head — so a bulk read that trips over one of those degrades to per-segment reads instead of
  failing the scan.
• Connection lifetimes are unchanged — every operation still opens and closes its connection —
  so Windows file-handle semantics and all existing tests are untouched.

Measurement

17 sessions × 100 events (one commit per event), traversing all sessions via readAfter(0, N):

storage instance model	main	this PR
new instance per session	~2.8s	~0.375s
one shared instance	~2.6s	~0.25s

And at a larger scale, 17 sessions × 3000 events (51,000 events, one commit per 5 events):

storage instance model	main	this PR
new instance per session	~12.6s	~1.6s
one shared instance	~12.8s	~1.4s

How to test

mvn -pl agentscope-harness -am test -Dtest='SqliteSessionStorageTest,WorkspaceSessionLogStoreTest'

All green, plus the full agentscope-core + agentscope-harness suites (4.5k tests) pass locally.

[ningmao-hlyz]

The Windows failure on the previous head was ToolConfirmationCoordinatorTest.managedTimeoutWaitsForControlPlaneCancelledDecision in service-dataplane — unrelated to the storage changes here. The same race class was already deflaked in #3616 for a sibling test in that file: the ticket's own 200ms poller thread observes the durable decision and releases the continuation, so resolveManaged can legitimately return OWNER_UNAVAILABLE when the poller drops the local waiter between the durable resolution and the owner lookup. The decision is accepted either way; only the return-code assertion was scheduling-dependent.

This branch deflakes it the same way (accepting RESOLVED or OWNER_UNAVAILABLE for that one assertion; the effect assertions — waiter released as cancelled, resolution status, decision event — stay exact).