Runtime Object Sharing for Scalable Session Isolation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Scalability and robustness in server systems are compromised due to the difficulty in achieving strong isolation between user sessions, particularly when handling a large number of user sessions, as traditional methods like allocating one operating system process per user session incur significant overhead and resource consumption.

Innovation Solution

Implementing techniques to share data and provide isolation between user sessions by identifying shareable data objects, grouping them into 'object groups', and copying these groups into a shared memory area, allowing for efficient reuse across multiple runtime systems while maintaining isolation through mechanisms like mapping and copying into address spaces.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If one operating system process is allocated for each user session to achieve strong isolation, then robustness is improved, but device complexity and resource consumption increase significantly

Engineering Contradiction:
ImproverobustnessVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

Multiple user sessions are merged into a single operating system process, sharing common resources such as the virtual machine and memory space. This reduces the total number of processes from O(n) to O(1), significantly lowering device complexity while maintaining isolation through software-based mechanisms rather than process-level separation.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

Instead of creating separate process instances for each user session, the system copies only the necessary data objects (such as user contexts, session state, and configuration data) into a shared memory area. This allows multiple sessions to access the same process while maintaining logical isolation through selective copying of shared versus private data.

Inventive Principle:
Principle #26Copying

2Reliability

If one operating system process is allocated for each user session, then isolation between sessions is improved, but loss of time increases due to OS scheduling overhead

Engineering Contradiction:
ImproveisolationVSAvoidscheduling overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Multiple user sessions are merged into a single process context, eliminating OS-level process scheduling overhead. The system uses a single thread or coroutine to service all user sessions sequentially, replacing costly context switches with cheaper stack switches or pointer manipulations within the same process address space.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The system segments user session data into distinct memory regions (shared memory area for common data, private memory for session-specific data). This allows the single process to efficiently switch between sessions by simply changing memory pointers rather than performing full process context switches, reducing time loss while maintaining isolation.

Inventive Principle:
Principle #1Segmentation

3Productivity

If data objects are shared between runtime systems to reduce resource consumption, then productivity is improved, but robustness may be compromised due to potential data conflicts

Engineering Contradiction:
Improveresource consumptionVSAvoidrobustness
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

Data objects are segmented into two categories: shared data objects that can be accessed by multiple runtime systems and private data objects that remain isolated to single sessions. The system traverses object graphs to identify which objects should be shared and which should remain private, allowing resource efficiency without compromising robustness through proper data separation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system introduces a shared memory area as an intermediary layer between runtime systems. Data objects are copied into this shared memory area with controlled access mechanisms, allowing multiple runtime systems to access the same data while the intermediary layer manages synchronization and isolation, preventing direct data conflicts.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Device complexity

If a large number of user sessions are handled in a single virtual machine, then device complexity is reduced, but measurement precision of system state decreases due to difficulty in tracking and managing sessions

Engineering Contradiction:
Improvedevice complexityVSAvoidsession state tracking
Core Design Contradiction:
Device complexityVSMeasurement precision

Solution Approach 1:

The system segments session state information into a structured format within the shared memory area, organizing data by session identifier and type. This allows the single virtual machine to track thousands of sessions efficiently through indexed memory access rather than maintaining complex in-process data structures, improving measurement precision while reducing device complexity.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS7587721B2Sharing objects in runtime systems
Publication Date: 2009.09.08 SAP SE
  • US7587721B2 patent drawing
  • US7587721B2 patent drawing
  • US7587721B2 patent drawing

AI summary

Method, apparatus and system for data sharing in runtime systems are described. A set of data objects is identified, where each data object in the set of data objects comprises a reference to runtime metadata about the data object in a first runtime system. For each data object in the set of data objects, the reference to the runtime metadata in the data object is replaced with a proxy. The set of data objects is transmitted to a second runtime system. The transmitting of the set of data objects includes replacing the proxy with the reference to the runtime metadata for each of the set of data objects transmitted to the second runtime system. Further, a shared memory is associated with the first runtime system and the second runtime system such that the first and second runtime systems share us information at the shared memory.