EJB Session Timeout Management via Shared Invalidation Agent
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing Java Enterprise Java Bean (EJB) container faces resource management issues due to the difficulty in determining when stateful session beans can be safely removed, leading to 'dead-letter' instances that consume server resources, and traditional LRU approaches result in unnecessary duplication of timeout management, potential resource leaks, slow disk access, and performance degradation.
Innovation Solution
A general-purpose timeout management system is introduced, where each EJB container instantiates an 'invalidation agent' that registers with a shared timeout service, using a 'timeout marker' to track object access, allowing the service to invoke callbacks at specified intervals and determine whether objects can be terminated based on access status.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If stateful session beans are kept in memory to maintain client-specific session data, then client session management capability is improved, but server resource consumption increases due to dead-letter instances
Solution Approach 1:
The system performs preliminary actions by setting timeout markers when session beans are created and periodically checking these markers to determine if beans should be removed. This proactive approach prevents resource accumulation by preparing for bean removal before resources are exhausted.
Solution Approach 2:
The timeout management system implements feedback mechanisms by continuously monitoring session bean access patterns and automatically triggering removal actions when timeout conditions are met. The system receives feedback from access checks and adjusts resource allocation accordingly.
2Quantity of substance
If LRU approach is used to remove timed-out beans, then resource management is improved, but system performance deteriorates due to disk access and clock queries
Solution Approach 1:
The invention extracts the timeout management functionality from the EJB container into a separate, shared timeout service. This separation eliminates the performance overhead of clock queries and disk access from the container's core operations, isolating the resource-intensive timeout management tasks.
Solution Approach 2:
Multiple EJB containers share a single timeout service instance, merging timeout management operations into one centralized component. This eliminates redundant timeout management code across multiple containers and consolidates resource-intensive operations.
3Ease of operation
If timeout management code is encapsulated within each EJB container, then container autonomy is improved, but system complexity increases due to service duplication
Solution Approach 1:
The timeout service is designed as a universal, shared component that can serve multiple EJB containers simultaneously. This multi-functional design allows a single timeout service instance to manage timeouts for all containers, eliminating the need for each container to maintain its own timeout management code.
Solution Approach 2:
The timeout service acts as an intermediary between EJB containers and session bean management. Containers interact with the shared timeout service rather than implementing timeout logic internally, simplifying the overall system architecture while maintaining container operational independence.
Data Source
AI summary
A method and apparatus to provide a general-purpose timeout management system for client-specific session objects. In one embodiment a timeout service is created that may be used by more than one Java Enterprise EJB container simultaneously, avoiding unnecessary duplication of timeout management services. Each EJB container may instantiate an “invalidation agent” which registers a callback interface with the timeout service. The timeout service invokes a timeout callback method on registered invalidation agents at specified time intervals. The time intervals correspond to the timeout values associated with the client-specific objects, obviating the need for the EJB container to make time-consuming queries to the system clock. The invention discloses a “timeout marker” data element associated with each client-specific session object created by the EJB container. Whenever a client accesses a client-specific session object, the timeout marker associated with that object is cleared. Then, when the invalidation agent's timeout callback is invoked, the invalidation agent checks the timeout marker on each registered object to determine whether it was accessed since the last timeout period. If the object was not accessed it may be terminated; otherwise it may be retained and re-marked.