ChatMemoryRepository is the storage abstraction behind MessageWindowChatMemory. Its default implementation keeps conversation messages in an in-memory Map, which is simple for getting started but loses history when the application restarts. section 5.2.1
The repository becomes useful when conversational memory is connected to a chat advisor. MessageChatMemoryAdvisor or PromptChatMemoryAdvisor receives MessageWindowChatMemory, which uses the repository to retrieve and store messages for each conversation. section 5.2.1
Choose the repository implementation according to the application’s persistence requirements:
- Use the default in-memory repository for simple applications and experiments; it does not survive restarts and continues consuming application memory during operation. section 5.2.1 section 5.3
- Use CassandraChatMemoryRepository for chat history stored in a scalable Cassandra cluster. section 5.4.1
- Use JdbcChatMemoryRepository with a configured DataSource and database dialect for JDBC-backed persistence. section 5.4.1
- Use Neo4jChatMemoryRepository when chat history belongs in a Neo4j database. section 5.4.1
Conversation identity must accompany each request. Extract a conversation ID from a request header and pass it to the advisor through the CONVERSATION_ID parameter; reusing the same ID lets follow-up questions access prior history, while a new ID starts separate history. section 5.3
Switching to persistent chat memory
Add the repository starter, inject ChatMemoryRepository into the ChatMemory bean, and supply it to MessageWindowChatMemory. Spring AI autoconfiguration creates the repository bean; the application must still provide the selected database, such as Cassandra, Neo4j, or PostgreSQL. section 5.4.1
@Bean
ChatMemory chatMemory(ChatMemoryRepository chatMemoryRepository) {
return MessageWindowChatMemory.builder()
.chatMemoryRepository(chatMemoryRepository)
.build();
}
The bean definition shows the key substitution point: MessageWindowChatMemory receives an injected ChatMemoryRepository instead of relying on its in-memory default. section 5.4.1
