Server Session Microcache for Reliable Multi-Client Communication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In a multi-client, multi-server environment, client requests can lead to uncertainty regarding processing status due to unreliable communications, resulting in potential duplicate processing or missed transactions, as clients are unsure if requests were received, processed, or if responses were successfully transmitted.
Innovation Solution
Implementing a server-specific session microcache that stores responses to client requests, allowing servers to resend cached responses instead of reprocessing requests and enabling clients to maintain a response list for tracking received responses, ensuring idempotent operations by using session IDs and correlation IDs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the client sends a request to the server, then the server processes the request, but the client cannot determine whether the request was received, processed, or if the response was successfully transmitted
Solution Approach 1:
The patent implements a feedback mechanism where the server sends acknowledgment responses to the client, and the client tracks these responses using correlation IDs. The client maintains a list of sent requests and their corresponding responses, allowing it to determine the status of each request. This feedback loop resolves the information loss problem by ensuring the client receives confirmation of request receipt and processing status.
Solution Approach 2:
The patent introduces a correlation ID as an intermediary element that links requests and responses. This correlation ID acts as a mediator between the client and server, allowing the client to track the status of requests without requiring direct inspection of server internal states. The correlation ID enables reliable tracking across potentially unreliable network communications.
2Reliability
If the client sends a request again when no response is received, then the client ensures transaction completion, but the server may process the request twice causing duplicate charges
Solution Approach 1:
The patent implements preliminary action by having the server record received requests in a cache structure before processing them. When a request is received, the server stores it with a unique correlation ID and acknowledgment status. This preliminary recording allows the server to recognize duplicate requests and prevent duplicate processing, while still allowing the client to retry if necessary.
Solution Approach 2:
The server sends feedback responses to the client confirming request receipt and processing status. The client uses this feedback information to determine whether to retry a request. This feedback mechanism prevents duplicate processing by informing the client when a request has been successfully received and processed, eliminating the need for blind retries that could cause duplication.
3Object-generated harmful factors
If the client does not re-send the request when no response is received, then the client avoids duplicate processing, but the server may never receive the request resulting in lost transactions
Solution Approach 1:
The server sends feedback responses to confirm request receipt and processing status. The client uses this feedback to make intelligent decisions about whether to retry. If the client receives confirmation that the request was processed, it knows not to retry. If no confirmation is received within a reasonable time, the client can retry. This feedback mechanism ensures both duplicate prevention and transaction completion.
Solution Approach 2:
The client maintains its own record of sent requests and received responses, autonomously determining when to retry based on its tracking. The client self-manages the retry logic by comparing its sent request list against received responses, eliminating the need for server intervention in the decision-making process while ensuring reliable transaction completion.
4Productivity
If the server stores responses in a session microcache, then the server can resend cached responses instead of reprocessing, but the system complexity increases
Solution Approach 1:
The patent segments the server's request handling into distinct phases: request receipt, processing, response generation, and caching. The session microcache is segmented by session ID, creating isolated storage spaces for different client sessions. This segmentation allows efficient caching and resending of responses without interfering with other sessions, improving productivity while managing complexity through structured organization.
Solution Approach 2:
The server creates a copy of the response and stores it in the session microcache instead of reprocessing the original request. This copying approach allows the server to resend the same response to the client without performing the expensive processing operation again. The copy is stored with the correlation ID, enabling quick retrieval and resending while avoiding duplicate processing work.
Data Source
AI summary
According to one aspect of the present disclosure, a method is implemented by a server in a server cluster. A request received from a client includes a session identifier (ID) identifying a session between the client and the server, and a correlation ID that is linked to the request. If the correlation ID is not included in an individual server-specific session microcache for the session, the request is processed to determine a response, the response is added to the session microcache, and the response and an indication of the correlation ID are sent to the client. If the correlation ID and a response to the request are stored in the session microcache, the response and an indication of the correlation ID are re-sent to the client. The session ID and session microcache are transferred to another of the plurality of servers in the server cluster to continue the session.