Mutable Key Mechanism for Persistent Object Garbage Collection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Enterprise JavaBeans and similar persistent objects have immutable primary keys, which restrict their ability to adapt to changing user identification information across multiple media servers, such as email and audio-conferencing servers, as user login status and identifying information can change over time.
Innovation Solution
Implementing a mechanism for generating objects with persistent data and mutable keys, allowing for garbage collection, by using a combination of regular Java classes and entity bean classes with finder methods that can update and manage multiple identifying information fields like email addresses and phone numbers, enabling dynamic key updates and efficient data management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If primary keys are made immutable as required by Enterprise JavaBean specification, then object persistence and database mapping are ensured, but adaptability to changing user identification information across multiple media servers is restricted
Solution Approach 1:
The patent segments the key into two parts: a permanent identifier (like SSN) that remains immutable and guarantees object persistence, and a mutable alias field that can change to adapt to different identification methods across media servers. This allows the object to maintain reliable persistence while gaining adaptability.
Solution Approach 2:
The patent introduces dynamic behavior by allowing the alias field to be updated over time. The key remains immutable for persistence guarantees, but the alias can dynamically change to reflect different identification methods (email, phone, etc.) across different media servers, resolving the contradiction between stability and adaptability.
2Adaptability or versatility
If all identifying information is specified initially when creating an entity bean, then data completeness is ensured, but the system cannot reflect changes in user login status or identification information over time
Solution Approach 1:
The patent enables dynamic updates by allowing the alias field to be modified after object creation. This permits the system to reflect changes in user login status across different media servers without requiring complex re-creation of the entire object, thus improving adaptability while managing complexity.
Solution Approach 2:
The patent uses the alias field as a copy or reference to different identification methods. Instead of managing multiple complex identifying fields directly, the alias acts as a flexible reference that can point to different identification methods (email, phone, etc.), simplifying the management of changing user status information.
3Adaptability or versatility
If a single primary key is used to identify users, then data storage efficiency is improved, but the system cannot handle users with multiple identifying information across different media servers
Solution Approach 1:
The patent segments the identification mechanism into a permanent key (for efficient single-column storage) and a mutable alias field (for supporting multiple identification methods). This allows the system to maintain data storage efficiency while gaining support for multiple identifying information across different media servers.
Solution Approach 2:
The patent changes the parameter of the alias field from immutable to mutable, allowing it to store different identification methods (email, phone, etc.) at different times. This enables the system to handle multiple identifying information without requiring multiple permanent key columns, thus managing data storage requirements while improving adaptability.
Data Source
AI summary
A mechanism is disclosed that enables garbage collection of object instances that have persistent data and a mutable key. A mutable key capability is advantageous in a variety of applications, such as monitoring a set of users and their login status on a plurality of media servers (e.g., an email server, an instant messaging server, a voice mail server, a video server, an audio-conferencing server, etc.). Implementations based on the Enterprise JavaBean specification are disclosed for three illustrative embodiments of the present invention. The illustrative embodiments of the present invention can also be implemented in accordance with object persistence mechanisms other than Enterprise JavaBeans.