iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Spring AI has not been shown to have formally deprecated or removed ChatMemory in a stable release. Its 2.1 upgrade notes say the community spring-ai-session project is planned to replace it; the 2.1.0-M1 reference still documents ChatMemory and says that documentation is not stable. If you are planning an upgrade, evaluate the Session API and map your identifiers and stored data deliberately—but do not treat it as a confirmed drop-in migration.
What is changing—and what has not been confirmed?
Spring AI’s upgrade notes state: “The spring-ai-session community project provides a session-aware memory implementation that fully supports tool-call messages and can be safely used inside the tool-call loop with any backend. It is planned to replace ChatMemory in Spring AI 2.1.” That is roadmap language, not a release-specific deprecation notice. The Spring AI 2.1.0-M1 reference says it is still in development and unstable, and identifies 2.0.1 as the latest stable version. The 2.1 upgrade notes describe the plan, not a completed replacement.
The community project is a separate project from Spring AI’s official API. The reviewed documentation does not establish a stable official migration path from ChatMemory, automatic conversion of persisted records, or a formal deprecation or removal date. Check the release notes and compatibility information for the exact versions you intend to deploy before changing production code.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →How do ChatMemory and Session differ?
ChatMemory selects and manages relevant conversational context across model interactions. Its repository stores and retrieves messages, while the memory implementation determines what context to retain—for example, a recent window. Spring AI distinguishes this working context from a complete transcript or audit history; for full records, its Chat Memory reference points to a separate storage approach such as Spring Data.
#1 Best Overall
The community Session API describes a structured, event-sourced model. Messages are session events with identity, timestamp, session ownership, and metadata. It includes a SessionRepository SPI, a session service, and documented compaction strategies intended to control active context while retaining the event history.
| Aspect | ChatMemory | Community Session API |
|---|---|---|
| Project and status | Spring AI API, documented in the stable 2.0.1 line; 2.1 documentation remains marked as in development. | Spring AI Community project; its replacement role is described as planned, not as a completed stable transition. |
| Core model | Repository stores messages; memory selects relevant conversational context. | Structured session events with identity, timestamp, ownership, and metadata. |
| Context management | Can retain a selected window of messages; not itself a complete audit-history solution. | Documents sliding-window, turn-window, token-count, and recursive-summarization compaction strategies. |
| Storage options | Repository choices depend on the Spring AI integration in use. | Project overview describes in-memory and JDBC options and lists Redis as a possible backend; the documented JDBC implementation supports PostgreSQL, MySQL, MariaDB, and H2. |
| Migration compatibility | Existing repositories and custom behavior are application-specific. | No automatic conversion of existing ChatMemory rows or general drop-in migration is established in the reviewed documentation. |
The Session project describes compaction triggers based on turn or token count. These are documented capabilities, not independently tested performance or behavior guarantees. See the Session project guide for its current model and implementation details.
What should you check before migrating?
Start by inventorying how your application creates, scopes, stores, and consumes conversation context. A new session identifier is not necessarily equivalent to an existing conversation identifier, and changing repositories without a data plan can disconnect users from their prior context.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11- Identity and lifecycle: Determine how a conversation maps to an authenticated user, tenant, and conversation lifecycle. Decide when a new session begins and when it ends.
- Existing persistence: Inspect the repository schema, stored message metadata, serialization format, retention policy, and any custom cleanup or audit requirements.
- Tool calls and advisors: Check whether your application relies on tool-call messages, custom advisors, or advisor ordering. Validate that the selected Session version preserves the behavior your flow needs.
- History requirements: Separate active prompt context from a complete transcript or compliance record. Compaction controls context; it should not be assumed to replace your application’s durable history store.
- Compatibility: Match the Session project’s requirements to your Java, Spring AI, and Spring Boot versions, then confirm them against the exact release’s documentation.
How to pass a session ID to SessionMemoryAdvisor
The community quickstart shows a JDBC starter, a SessionService, and a SessionMemoryAdvisor. It passes the session ID as a per-call advisor parameter using SessionMemoryAdvisor.SESSION_ID_CONTEXT_KEY. In this pattern the advisor loads history, appends messages, and applies configured compaction triggers.
The guide currently states Java 17+, Spring AI 2.0.1+, and Spring Boot 4.1.1+ as requirements. Treat these as the guide’s stated baseline, not a guarantee that every combination or later release is compatible; verify the selected artifact’s version-specific requirements. The following is the documented usage shape, not a tested migration from an existing application:
SessionMemoryAdvisor advisor = SessionMemoryAdvisor.builder(sessionService)
.compactionTrigger(new TurnCountTrigger(20))
.compactionStrategy(
SlidingWindowCompactionStrategy.builder().maxEvents(10).build())
.build();
ChatClient chatClient = ChatClient.builder(chatModel)
.defaultAdvisors(advisor)
.build();
String answer = chatClient.prompt()
.user("What is Spring AI?")
.advisors(a -> a.param(
SessionMemoryAdvisor.SESSION_ID_CONTEXT_KEY, "session-abc"))
.call()
.content();For the JDBC setup and dependency coordinate, consult the community quickstart; it documents org.springaicommunity:spring-ai-starter-session-jdbc. Adapt its example to your dependency-management and configuration setup rather than assuming the sample alone handles existing data migration.
How should you map conversation IDs?
Current Spring AI memory advisors require ChatMemory.CONVERSATION_ID; omitting it causes an IllegalArgumentException. The Spring AI 2.0 upgrade notes also say ChatMemory.DEFAULT_CONVERSATION_ID was removed, so applications must supply an explicit conversation ID or derive one from session or user context. The Session guide instead uses SessionMemoryAdvisor.SESSION_ID_CONTEXT_KEY for advisor context.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsDo not mechanically copy an old conversation ID into the Session API without checking its meaning. Define how the Session ID is generated, scoped, authorized, and persisted in your application. If you enable recall tools, the Session migration guidance for version 0.9.0 says conversation_search also needs the session ID in tool context. Confirm the requirement for the version you use in the Session migration guide.
Best Value
Which separate Spring AI memory changes may affect an upgrade?
Not every memory-related upgrade note is part of the Session roadmap. Spring AI 1.0 included repository naming and package changes, while Spring AI 2.0 changed conversation-ID and advisor behavior. Handle these against their own version-specific notes rather than treating them as evidence that ChatMemory has already been replaced.
Quick Recap
- Spring AI 1.0: Memory artifact names gained a
repositorysuffix, package paths gained.repository., auto-configuration class names gainedRepository, and properties moved fromspring.ai.chat.memory.<storage>...tospring.ai.chat.memory.repository.<storage>.... The notes also record removal ofCassandraChatMemory, simplification of the advisor hierarchy, and removal of deprecated JDBC APIs. See the Spring AI 1.0 upgrade notes. - Spring AI 2.0:
ChatMemory.DEFAULT_CONVERSATION_IDwas removed and memory advisors require a conversation ID. The notes also describe replacingPromptChatMemoryAdvisorwithMessageChatMemoryAdvisor; the latter supplies history as typed message objects rather than embedding it in the system prompt. See the Spring AI upgrade notes.
What is a safe migration sequence?
- Pin down the target versions. Record your Spring AI, Spring Boot, Java, and Session dependency versions. Verify the community project’s stated baseline and any release-specific compatibility information.
- Document current behavior. Capture your conversation-ID rules, repository schema, retained context policy, tool-call flows, advisor order, and any separate transcript or audit storage.
- Prototype with an isolated session. Follow the community guide to configure a repository and advisor, then verify history retrieval, message appends, tool calls, and compaction using your application’s own flows.
- Design data continuity explicitly. Decide whether to leave old ChatMemory records readable, transform them, or begin new sessions. The reviewed documentation does not provide an automatic conversion, so define and test any conversion yourself.
- Test failure and isolation cases. Verify that missing or invalid IDs fail safely, one user cannot access another user’s session, and repository outages or compaction do not erase any transcript your application must preserve.
- Deploy behind a controlled transition. Use a reversible rollout appropriate to your system, monitor session retrieval and persistence, and retain a rollback path until the selected versions and data behavior are validated.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
