System and Method for Efficient Storage of Long-Lived Session State in a SIP Server

• US 20090006598A1
• Filed: 12/13/2007
• Published: 01/01/2009
• Est. Priority Date: 12/13/2006
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: BEA Systems Incorporated (Oracle Corporation)
• Inventors: Kramer, Reto, Devine, Paul James, Mehra, Vinod, Cosmadopoulos, Ioannis
• Granted Patent: US 8,078,737 B2
• Time in Patent Office: Days
• US Class Current: 709/223
• CPC Class Codes: G06F 16/957 Browsing optimisation, e.g. caching or content distillation
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066

Abstract

A SIP server can be deployed in a two-tier architecture, including an engine tier for processing of SIP communications and a state tier for maintaining the state associated with these communications. The state tier can include RAM-based replicas that provide data to the engines. Some of the SIP session state can be moved to the database in order to reduce the memory requirements of the state tier. Upon determining that a transaction boundary has been reached where the session state is steady, the state replica can save the data to the database. A hint can be received from the engine tier by the state replica indicating that the state data is ready to be saved. Subsequently, the data can be removed from the state tier by nulling out the bytes of actual data, while preserving the primary key, locking and timer information so as not to impact latency.

Claims

1. A system for efficient storage of session state data, said system comprising:

a cluster network of computer servers, said network including at least one engine node that processes transactions and at least one state replica that stores said session state data associated with said transactions in random access memory (RAM) thereon; and

a database connected to said cluster network, wherein said database stores a portion of said session state data; and

wherein said state replica determines that a transaction boundary has been reached such that said portion of the session state data is determined to be steady and replicates the portion of the session state data to the database upon reaching said transaction boundary.

2. The system according to claim 1 wherein said state replica removes said portion of state data from the RAM thereon after replicating said portion of the session state data to the database.

3. The system according to claim 2 wherein said state replica removes said portion of state data from the RAM by nulling out the byte array holding the session state data, while preserving, in said RAM, at least one of:

a primary key associated with said session state data;

a set of timer objects associated with said session state data; and

locking information associated with said session state data.

4. The system according to claim 2 wherein said state replica notifies all other state replicas in a same partition as said state replica to remove said portion of the session state data after it has been replicated to said database.

5. The system according to claim 1 wherein determining that a transaction boundary has been reached further includes:

receiving a hint by the state node from the engine node, said hint indicating that the engine has determined that the portion of said session state will not be altered within a specified period of time.

6. The system according to claim 1 wherein determining that a transaction boundary has been reached further includes:

receiving a hint by the engine node from an application deployed thereon, said hint indicating that the application has determined that the portion of said session state will not be altered within a specified period of time; and

relaying said hint to the state node by the engine node.

7. The system according to claim 5 wherein determining that a transaction boundary has been reached further includes:

determining by the state node whether to follow or disregard said hint based on at least one of;

a subsequent request for said session state data received from said engine node, an amount of available memory on said state node, and an aggregate view of steady state across all applications in a session associated with said session state data.

8. The system according to claim 1 wherein each server in said cluster network is a session initiation protocol (SIP) server and wherein determining that a transaction boundary has been reached further includes determining, by the engine node, that at least one of the following has occurred:

a subscription session has been established by a SIP cable box client with said SIP server; and

a telephone call has been setup by a SIP telephone client with said SIP server.

9. The system according to claim 1 wherein replicating said portion of the session state data to the database by the state node further includes:

enqueueing, by a first thread, a task to update the database to an execute queue maintained in said state node;

releasing said first thread; and

initiating a second thread to dequeue said task from the execute queue and to perform the update operation on the database.

10. The system according to claim 1 wherein said state replica receives a new request for said session state data from said engine node and retrieves said session state data from the database if the session state data has been removed from the RAM of said state replica.

18. The system according to claim 1 wherein each server in said computer network is a session initiation protocol (SIP) server and wherein determining that a transaction boundary has been reached further includes determining, by the engine node, that at least one of the following has occurred:

a subscription session has been established by a SIP cable box client with said SIP server; and

a telephone call has been setup by a SIP telephone client with said SIP server.

11. A computer implemented method for efficiently storing session state data, said method comprising:

maintaining a computer network of server nodes, said network including at least one engine node that processes transactions and at least one state replica node that stores the session state data associated with said transactions;

receiving an update to said session state from an engine node to a state replica node;

storing said update to the session state data in the state replica node;

determining, by said state replica node, whether a transaction boundary has been reached such that said session state data is determined to be steady;

transmitting said session state data to a database by said state replica node upon determining that said transaction boundary has been reached; and

removing said session state data from the state replica node.

12. The method according to claim 11 wherein transmitting said session state to a database by said state replica node includes:

replicating a portion of said session state to the database

13. The method according to claim 11 wherein removing said sessions state data from the replica node further includes:

nulling out the byte representation of said session state data on the state replica node while preserving, on said state replica node, at least one of;

a primary key associated with said session state data, timer objects associated with said session state data, and locking information associated with said session state data.

14. The method according to claim 11 further comprising:

notifying, by said state replica node, all other state replica nodes in a same partition as said state replica to remove said session state data after it has been transmitted to said database.

15. The method according to claim 11 wherein determining that whether a transaction boundary has been reached further includes:

receiving a hint by the state node from the engine node, said hint indicating that the engine has determined that the portion of said session state will not be altered within a specified period of time.

16. The method according to claim 11 wherein determining that whether a transaction boundary has been reached further includes:

receiving a hint by the engine node from an application deployed thereon, said hint indicating that the application has determined that the portion of said session state will not be altered within a specified period of time; and

relaying said hint to the state node by the engine node.

17. The method according to claim 15 wherein determining whether a transaction boundary has been reached further includes:

determining by the state node whether to follow or disregard said hint based on at least one of;

a subsequent request for said session state data received from said engine node, an amount of available memory on said state node, and an aggregate view of steady state across all applications in a session associated with said session state data.

19. The method according to claim 11 wherein transmitting said session state data to the database by the state node further includes:

enqueueing, by a first thread, a task to update the database to an execute queue maintained in said state node;

releasing said first thread; and

initiating a second thread to dequeue said task from the execute queue and to perform the update operation on the database.

20. A computer-readable medium having instructions stored thereon which when executed by one or more processors cause a system to:

maintain a computer network of server nodes, said network including at least one engine node that processes transactions and at least one state replica node that stores the session state data associated with said transactions;

receive an update to said session state from an engine node to a state replica node;

store said update to the session state data in the state replica node;

determine, by said state replica node, whether a transaction boundary has been reached such that said session state data is determined to be steady;

transmit said session state data to a database by said state replica node upon determining that said transaction boundary has been reached; and

remove said session state data from the state replica node.