US8281014B2 - Session lifecycle management within a multi-tiered enterprise network - Google Patents

Session lifecycle management within a multi-tiered enterprise network Download PDF

Info

Publication number
US8281014B2
US8281014B2 US11/025,549 US2554904A US8281014B2 US 8281014 B2 US8281014 B2 US 8281014B2 US 2554904 A US2554904 A US 2554904A US 8281014 B2 US8281014 B2 US 8281014B2
Authority
US
United States
Prior art keywords
session
objects
session object
lifecycle
relationship
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/025,549
Other versions
US20060155756A1 (en
Inventor
Georgi Stanev
Galin Galchev
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Priority to US11/025,549 priority Critical patent/US8281014B2/en
Assigned to SAP AKTIENGESELLSCHAFT reassignment SAP AKTIENGESELLSCHAFT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GALCHEV, GALIN, STANEV, GEORGI
Publication of US20060155756A1 publication Critical patent/US20060155756A1/en
Application granted granted Critical
Publication of US8281014B2 publication Critical patent/US8281014B2/en
Assigned to SAP SE reassignment SAP SE CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: SAP AG
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/142Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/957Browsing optimisation, e.g. caching or content distillation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for managing related session lifecycles within an enterprise network.
  • FIG. 1 a Traditional client-server systems employed a two-tiered architecture such as that illustrated in FIG. 1 a .
  • Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101 .
  • a database 104 maintained on the server 101 provides non-volatile or “persistent” storage for the data accessed and/or processed by the application 102 .
  • the “business logic” component of the application represents the core program code of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application.
  • the “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface.
  • the “database” 104 includes data access logic used by the business logic to store and retrieve data.
  • the limitations of the two-tiered architecture illustrated in FIG. 1 a become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
  • FIG. 1 b a multi-tiered architecture has been developed, as illustrated in FIG. 1 b .
  • the presentation logic 121 , business logic 122 and database 123 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers on the network 103 .
  • the presentation logic 121 , the business logic 122 , and the database 123 may each be maintained on separate servers, 126 , 127 and 128 , respectively.
  • This separation of logical components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122 . If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code.
  • presentation logic 121 may be provided which generates code for a variety of different user interfaces 120 , which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
  • the multi-tiered architecture illustrated in FIG. 1 b may be implemented using a variety of different application technologies at each of the layers of the multi-tier architecture, including those based on the Java TM2 Enterprise Edition (“J2EETM”) standard, the Microsoft .NET standard and/or the Advanced Business Application Programming (“ABAP”) standard developed by SAP AG.
  • J2EETM Java TM2 Enterprise Edition
  • ABP Advanced Business Application Programming
  • the business layer 122 which handles the core business logic of the application, is comprised of Enterprise Java Bean (“EJBTM”) components with support for EJB containers.
  • EJBTM Enterprise Java Bean
  • the presentation layer 121 is responsible for generating servlets and Java Server Pages (“JSPTM”) interpretable by different types of browsers at the user interface layer 120 .
  • FIG. 2 a illustrates a typical J2EE application server 200 in which the presentation layer is implemented by a “Web container” 211 and the business layer is implemented by an Enterprise Java Bean (“EJB”) container 201 .
  • Containers are runtime environments which provide standard common services 219 , 209 to runtime components.
  • the Java Naming and Directory Interface (“JNDI”) is a service that provides application components with methods for performing standard naming and directory services.
  • Containers also provide unified access to enterprise information systems 217 such as relational databases through the Java Database Connectivity (“JDBC”) service, and legacy computer systems through the J2EE Connector Architecture (“JCA”) service.
  • JDBC Java Database Connectivity
  • JCA J2EE Connector Architecture
  • containers provide a declarative mechanism for configuring application components at deployment time through the use of deployment descriptors.
  • each layer of the J2EE architecture includes multiple containers.
  • the Web container 211 is itself comprised of a servlet container 215 for processing servlets and a Java Server Pages (“JSP”) container 216 for processing Java server pages.
  • JSP Java Server Pages
  • the EJB container 201 includes three different containers for supporting three different types of enterprise Java beans: a session bean container 205 for session beans, a entity bean container 206 for entity beans, and a message driven bean container 207 for message driven beans.
  • J2EE containers and J2EE services can be found in R AGAE G HALY AND K RISHNA K OTHAPALLI , SAMS T EACH Y OURSELF EJB IN 21 D AYS (2003) (see, e.g., pages 353-376).
  • An application server 200 manages “session data” associated with each client interaction.
  • the session data defines the current conversational state between the client and the application server. For example, if the user is purchasing books from an online bookstore, the session data may define the current state of the user's “shopping cart” (e.g., the books the user has selected for purchase). Similarly, if the user is logged in to a particular Web portal (e.g., “My Yahoo”), the session data may define the state of the Web pages opened in the user's Web browser.
  • a particular Web portal e.g., “My Yahoo”
  • an HTTP session object 241 e.g., an instance of javax.servlet.HttpSession
  • multiple session beans 251 - 253 may be managed within the EJB container 250 .
  • Additional HTTP session objects 242 and session beans 254 - 255 may be managed concurrently to define the conversational state with additional clients 231 for the same application (e.g., the shopping cart application) or other applications (e.g., a “search” application).
  • the state of any given set of applications such as the user's shopping cart may be spread across multiple containers.
  • a system and method are described for managing session lifecycles within a multi-tiered enterprise network.
  • a plurality of session objects are generated at different layers of the enterprise network in response to a client request.
  • Each of the session objects store session data defining a state of interaction with the client.
  • one embodiment of the invention manages the lifecycle of a first session object based on corresponding lifecycles of one or more related session objects and also the type of relationship existing between the first session object and the one or more related session objects.
  • the defined relationship types include strong references, weak references, and soft references.
  • FIG. 1 a illustrates a traditional two-tier client-server architecture.
  • FIG. 1 b illustrates a prior art multi-tier client-server architecture.
  • FIG. 2 a illustrates a multi-tiered application server architecture according to the Java 2 Enterprise Edition (“J2EE”) standard.
  • J2EE Java 2 Enterprise Edition
  • FIG. 2 b illustrates different types of session data maintained within a multi-tiered enterprise architecture.
  • FIG. 3 illustrates a cluster architecture employed in one embodiment of the invention.
  • FIG. 4 illustrates a session domain hierarchy according to one embodiment of the invention.
  • FIG. 5 illustrates an exemplary set of related session data managed at various different layers of an enterprise architecture.
  • FIGS. 6 a - c illustrate session domain hierarchies associated with the exemplary set of session data shown in FIG. 5 .
  • FIG. 7 illustrates a session domain according to one embodiment of the invention.
  • FIG. 8 illustrates a session object according to one embodiment of the invention that includes a system part and a separate user part.
  • FIG. 9 illustrates a shared memory implementation of one embodiment of the invention.
  • FIG. 10 illustrates state transitions for session objects implemented in one embodiment of the invention.
  • FIG. 11 illustrates one embodiment for managing session objects having strong references.
  • FIG. 12 illustrates one embodiment for managing session objects having soft references.
  • FIG. 13 illustrates one embodiment for managing session objects having weak references.
  • FIG. 14 illustrates a session representation used in one embodiment of the invention.
  • Described below is a system and method for managing session lifecycles within a multi-tiered enterprise network.
  • numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.
  • FIG. 3 A system architecture according to one embodiment of the invention is illustrated in FIG. 3 .
  • the architecture includes a plurality of application server instances 301 and 302 .
  • the application server instances 301 and 302 each include a group of worker nodes 212 - 314 and 315 - 316 , respectively, and a request handler 311 and 312 , respectively.
  • the application server instances 301 , 302 communicate through a central services instance 300 using message passing.
  • the central services instance 300 includes a locking service and a messaging service (described below).
  • the combination of all of the application server instances 301 and 302 and the central services instance 300 is referred to herein as a “cluster.” Although the following description will focus solely on instance 301 for the purpose of explanation, the same principles apply to other instances within the cluster.
  • the worker nodes 312 - 314 within instance 301 provide the business and/or presentation logic for the network applications supported by the system.
  • Each of the worker nodes 312 - 314 within a particular instance may be configured with a redundant set of application logic and associated data, represented as virtual machines 321 - 323 in FIG. 3 .
  • the request handler 311 distributes service requests from clients to one or more of the worker nodes 312 - 314 based on the load on each of the servers. For example, in one embodiment, the request handler maintains separate queues for each of the 312 - 314 in shared memory 340 . The request handler 311 fills the queues with client requests and the worker nodes 312 - 314 consume the requests from each of their respective queues.
  • the worker nodes 312 - 314 may be Java 2 Enterprise Edition (“J2EE”) worker nodes which support Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer).
  • J2EE Java 2 Enterprise Edition
  • EJB Enterprise Java Bean
  • JSP Java Server Pages
  • the virtual machines 321 - 325 implement the J2EE standard (as well as the additional non-standard features described herein). It should be noted, however, that the embodiments of the invention described herein may be implemented in the context of various different software platforms including, by way of example, Microsoft .NET platforms and/or the Advanced Business Application Programming (“ABAP”) platforms developed by SAP AG, the assignee of the present application.
  • ABP Advanced Business Application Programming
  • the central services instance 300 includes a messaging service and a locking service.
  • the message service allows each of the servers within each of the instances to communicate with one another via a message passing protocol. For example, messages from one server may be broadcast to all other servers within the cluster via the messaging service (e.g., such as the cache configuration messages described below). Alternatively, messages may be addressed directly to specific servers within the cluster (i.e., rather than being broadcast to all servers).
  • the locking service disables access to (i.e., locks) certain specified portions of configuration data and/or program code stored within a central database 345 .
  • the locking service locks data on behalf of various system components which need to synchronize access to specific types of data and program code.
  • the central services instance 300 is the same central services instance as implemented within the Web Application Server version 6.3 developed by SAP AG. However, the underlying principles of the invention are not limited to any particular type of central services instance.
  • a session management layer 330 is executed within each of the instances 301 - 302 .
  • the session management layer 330 is comprised of the program code, interfaces and data for implementing the various session management techniques described herein.
  • one embodiment of the session management layer 330 manages session objects within session domains as described in detail below (see, e.g., FIG. 4 and associated text).
  • one embodiment of the invention shares objects across virtual machines 321 - 325 .
  • objects such as session objects which are identified as “shareable” are stored within a shared memory region 340 , 341 and are made accessible to multiple virtual machines 321 - 325 .
  • Creating new object instances from scratch in response to client requests can be a costly process, consuming processing power and network bandwidth.
  • sharing objects between virtual machines as described herein improves the overall response time of the system and reduces server load.
  • a shared memory area 340 , 341 or “heap” is used to store data objects that can be accessed by multiple virtual machines 321 - 325 .
  • the data objects in a shared memory heap should generally not have any pointers or references into any private heap (e.g., the private memory regions/heaps of the individual virtual machines). This is because if an object in the shared memory heap had a member variable with a reference to a private object in one particular virtual machine, that reference would be invalid for all the other virtual machines that use that shared object.
  • this restriction can be thought of as follows: For every shared object, the transitive closure of the objects referenced by the initial object should only contain shared objects at all times. Accordingly, in one implementation of the server 200 , objects are not put into the shared memory heap by themselves—rather, objects (such as the session objects described herein) are put into the shared memory heap in groups known as “shared closures.” A shared closure is an initial object plus the transitive closure of all the objects referenced by the initial object.
  • multiple related session objects may be managed within different tiers of an application server in response to a single client request, or series of client requests.
  • a single application may support several concurrent client sessions, resulting in several sets of session objects for each client.
  • One embodiment of the session management layer 330 employs a hierarchical structure for storing different types of related session data within each enterprise application (e.g., HTTP sessions, session EJBs, etc).
  • one embodiment of the session management layer groups related session objects within a logical hierarchy.
  • a session context object 400 At the top of the hierarchy is a session context object 400 .
  • Session domains are the base configurable objects within the session hierarchy and are positioned beneath the session context 400 .
  • the session domains represent abstract storage units for sessions that have similar characteristics (e.g., similar life cycles, applications, etc).
  • session objects 411 and 412 are managed within session domain 410
  • session objects 421 and 422 are managed within session domain 420 .
  • Both session domains 410 and 420 are positioned directly beneath the session context 400 .
  • each session domain 410 and 420 contains session objects related to different applications.
  • session domain 410 may contain session objects related to a “shopping cart” application and session domain 420 may contain session objects related to a “calculator” application.
  • Two additional session domains 430 and 440 are logically positioned beneath session domain 410 within the hierarchy.
  • these session domains 430 and 440 include session objects 431 , 432 and 441 , 442 , respectively, from the same application associated with session domain 410 .
  • session domains 430 and 440 include session objects related to the shopping cart application.
  • Grouping session objects for an application within the same session domain provides a consistent, logical way to manage session data. For example, as describe below with respect to FIG. 7 , different session policy and configuration parameters may be applied to each session domain such as, for example, session timeout periods and different storage implementations (e.g., shared memory, persistent storage, . . . etc).
  • a different session context 400 and associated hierarchy of session domains is maintained by the session management layer 330 for each layer of the application server.
  • This embodiment will be described using the example illustrated in FIG. 5 in which a plurality of session objects are managed for two different applications, identified as applications “A” and “B.”
  • the conversational state between client 530 and application A is maintained via three session bean objects 501 - 503 within the EJB container 542 ; an HTTP session object 511 within the Web container 540 ; and two portal session objects 520 - 521 within the enterprise portal container.
  • the conversational state between client 531 and application A is maintained via two session bean objects 504 , 506 , one HTTP session object 512 , and one portal session object 522 .
  • the conversational state between client 532 and application B is maintained via two session bean objects 507 - 508 , one HTTP session object 513 , and one portal session object 523 .
  • session bean objects 501 and 504 are instances of a particular session bean, “EJB A,” and session bean objects 502 and 506 are instances of another session bean, EJB B.
  • Session bean objects 503 , 507 and 508 are instances of session beans C, D and E, respectively.
  • the enterprise portal container 541 is built on top of the Web container 540 .
  • a single HTTP session object 511 may be related to multiple portal session objects 521 , 521 , which store user-specific session data for a plurality of user-specific Web content (e.g., Web pages) generated during the session.
  • user-specific Web content e.g., Web pages
  • a single HTTP session object 511 is managed within the Web container 540 and separate portal session data related for each individual window of the user's browser is stored within the portal session objects 520 - 521 .
  • the HTTP session object 511 manages session data related to the entire user session with the application server, whereas the portal session objects store session data for specific pages generated during the session (e.g., “My Yahoo” pages on the “Yahoo” Website).
  • each different type of session object shown in FIG. 5 is managed within a session domain under a different context.
  • a session domain For example, as illustrated in FIG. 6 a , separate session domains 610 and 620 , are maintained for applications A and B, respectively, under session bean context 600 .
  • a separate EJB session domain is used to store and manage session instances for each session bean of each application.
  • session domain 630 associated with EJB A stores session objects 501 , 504 which are instances of session bean A; session domain 640 associated with EJB B stores session objects 502 , 506 which are instances of session bean B; and session domain 650 associated with EJB C stores session objects 503 which are instances of session bean C.
  • session domain 660 associated with EJB D stores session objects 507 which are instances of session bean D
  • session domain 670 associated with EJB E stores session objects 508 which are instances of session bean E.
  • HTTP session domains 611 and 621 associated with applications A and B, respectively are managed under an HTTP session context 601 .
  • the HTTP session domains store session data associated with each applications' HTTP sessions. For example, HTTP session objects 511 and 512 are stored within the session domain 611 for application A, and HTTP session object 513 is stored within the session domain 621 for application B.
  • portal session domains 612 and 622 associated with applications A and B, respectively are managed under an application portal session context 602 .
  • the portal session domains store portal session objects containing portal data associated with each application.
  • portal session objects 520 - 522 are stored under the portal session domain 612 for application A
  • portal session object 523 is stored under the session domain 622 for application B.
  • FIG. 7 illustrates additional details related to the configuration of each session domain 700 according to one embodiment of the invention.
  • each session domain 700 includes a set of configuration policy objects 703 , a set of local storage attributes 702 and a set of global storage attributes 701 .
  • the configuration policy objects 703 define the behavior of each session domain.
  • the configuration policies implemented by the policy objects include, but are not limited to, a “thresholds” policy for setting limits on the number of sessions objects which are stored within each domain. For example, one session object may be joined to one or more session requests based on the thresholds policy.
  • a session access policy is implemented which allows the application or other entity which created the session domain (the “domain owner”) to restrict or otherwise influence session access. For example, the domain owner may prevent multithreaded session access via the session access policy.
  • the configuration policy 703 further includes a session invalidation policy which defines the behavior of the session object in the case of session invalidation. For example, as described in greater detail below, in one embodiment, transparent session objects are employed under certain conditions.
  • inactive sessions may be stored to persistent storage (e.g., the database or file system) and reactivated at a later time in response to subsequent requests.
  • a persistence policy is also implemented within the configuration policy objects 703 to define whether persistent storage should be used and, if so, the particular type of persistent storage that should be used.
  • Session persistence types may include, but are not limited to, in-memory session persistence (i.e., session objects within the domain are stored within the memory of a single process); in-memory replication persistence (i.e., session object state is stored within a server process memory and is replicated to other server processes); database-based persistence (i.e., the session objects are stored in the database and may be shared across server processes); file system persistence (i.e., sessions are stored within a directory of the file system and can be shared across processes); and cookie-based persistence (i.e., session data is stored within the client in a cookie). It should be noted, however, that the underlying principles of the invention are not limited to any particular set of configuration properties.
  • the global storage attributes 701 of each session domain 700 define attributes of the session domain which are shared across different virtual machines (e.g., different instances of the session domain implemented on different virtual machines).
  • the global session attributes may specify that all sessions within the particular domain 700 have the same expiration time (e.g., become inactive/invalid after a period of non-responsiveness from a client).
  • EJB application descriptors may be parsed once and shared between each of the EJB domains located under the session bean context 600
  • Web application descriptors may be parsed only once and shared between each of the session objects located under the HTTP session context 601 .
  • global storage attributes are used only in a shared memory implementation (i.e., in which virtual machines 321 - 325 share session objects via shared memory 340 - 341 as described herein).
  • global attributes are identified in shared memory using a unique global attribute name.
  • the local storage attributes 702 of the session domain define session attributes which are specific to each individual virtual machine (i.e., they are container-specific). For example, if a particular virtual machine relies on a socket connection to a particular remote server, then this information may be provided within the local storage attributes. Local storage attributes may also include specific references to files within the file system/database and specific references to database connections. In an embodiment which does not employ a shared memory implementation, all attributes of the session domain 700 are stored within the local storage attributes 702 .
  • the different containers can use the local storage attributes 702 to keep certain attributes banded to each concrete server process.
  • the HttpSession includes the method javax.servlet.ServletContext getServletContext ( ).
  • ServletContext can not be shared between different virtual machines because it maintains references to different resources that are local for the concrete server process.
  • the Web container binds the ServletContext as a local attribute for the session domain.
  • the getServletContext( ) method is implemented to provide a lookup of this attribute from the SessionDomain. Using this technique, the getServletContext( ) will return different objects based on the server process where the session is activated.
  • each session object 710 is logically separated into two different sub-parts or sub-objects: a system object 801 for storing system session data and a user object 802 for storing user session data.
  • the system object 801 includes data used by the application container 820 for session identification and session life cycle management (described in greater detail below). For example, the system object 801 includes the time that the session was created and the last time the session was accessed. The application container reads this information to determine whether the session object 710 should move from a valid to an invalid (active state is the state when we have requests to the session) state (e.g., if it has not been accessed by an application for an extended period of time).
  • the system object 801 also includes system data indicating whether the session object is to be stored in persistent storage (e.g., the database or file system) and/or shared memory (e.g., whether the session object is non-shareable or “sticky”), the state of the session (e.g., valid, invalid, transparent, removed), and the session domain ID.
  • persistent storage e.g., the database or file system
  • shared memory e.g., whether the session object is non-shareable or “sticky”
  • the state of the session e.g., valid, invalid, transparent, removed
  • the user object 802 includes user data typically accessed by applications 810 (rather than by the container). This may include, for example, user-specific session data for a particular Web page and/or data related to the current state of the user's browser. In one embodiment, all attributes stored in the HttpSession from the application are stored in the user object. In addition, the instances of each statefull EJB object may also be stored in the user object.
  • the session management layer 330 relies on the separation between system and user data to improve the efficiency with which the container and/or application accesses the session data.
  • the system object 801 is typically much smaller in size than the user object 802 and is not modified very frequently (although it may be accessed frequently). Thus, in one embodiment, the system object 801 is optimized for read access. For example, the system object 801 may be cached in main memory (shared memory 330 and/or local memory within the server on which the VM is executed) rather than being stored in persistent storage.
  • the user object 802 which is significantly larger than the system object 801 , may be stored to persistent storage.
  • the user session data is separated in the one or more independently-accessible parts called “delta attributes.” Because each of the delta attributes can be read independently from other attributes the entire block of system data does not need to be read to retrieve a particular attribute, thereby further improving efficiency.
  • the delta attributes represent the changes in the user data since the last time the user object was accessed. Reading only changes in the user data rather than all of the user data further improves access time.
  • the delta attributes are stored/retrieved in the session using addDelta/getDelta methods of the Session. Any attribute of an object can be stored as a delta attribute in the session object.
  • the delta attributes are not read from the backend store when the session is activated. Rather, the delta attributes are read only when the client attempts to retrieve them using the getDelta( ) method.
  • both the container 820 and applications 810 generate a session request, identifying the session by its name.
  • the session management layer 330 maintains a name-object mapping (e.g., within a mapping table) to identify the session object 710 using its name.
  • the session management layer 330 determines which portion of the session object to provide to the requestor based on the type of requestor. For example, in response to session requests from the container 820 , the session management layer 330 provides system data from within the system data object 801 , whereas in response to session requests from applications 810 , the session management layer 330 provides user data from the user data object 802 .
  • the mechanism for retrieving the correct set of data is transparent to the requester.
  • the container 820 and applications 810 may directly access the system data 801 and user data 802 , respectively.
  • session objects are managed differently depending on the objects' state. For example, “active” session objects generated in response to a session request are maintained within the local memory (or “heap”) of the virtual machine in which the session request originated. However, in a shared memory implementation, when a session object becomes inactive (e.g., due to a lack of interaction with the requestor), it is transferred to shared memory 340 - 341 so that it may be reused by other virtual machines. Thus, at any given time, session objects 710 from a particular session domain 700 may be stored in local memories of each virtual machine and/or the shared memory (and/or persistent storage).
  • each session domain 700 is logically separated into a local portion which contains active sessions, and a shared portion, which contains inactive sessions.
  • persistent storage such as the database or file system may be used to store inactive session objects in an analogous manner.
  • an “active” session is one which is currently in use by the application and can be modified.
  • the runtime representation contains all fields and members of the session object, which are directly accessible by the application.
  • In “inactive” session object is one which is not currently being used by the application.
  • Inactive session object are prepared to be written to shared memory and/or persistent storage in their serialized and/or shareable form, respectively. These session objects may be provided with additional member values used to restore the original state of the object after copying from shared memory or deserialization from persistent storage.
  • an active session object 901 is generated within virtual machine 321 .
  • the session object may then be modified in its active state, resulting in a modified active session object 903 .
  • the modified active session object 903 eventually changes state to an inactive session object 902 which is stored within shared memory 340 in a shared memory implementation.
  • the inactive session object 902 may be serialized and stored within the database and/or file system 910 , or simply stored within the local memory heap.
  • the inactive session may be accessed from any virtual machine.
  • a second session request is illustrated in both virtual machine 321 and virtual machine 322 .
  • the inactive session object is activated and copied back to the virtual machine where the second request originated.
  • the session object may then be accessed and modified again, as described herein.
  • the system data portion 801 of the session object may be accessed, whereas, in response to an application session request, the user data portion 802 of the session object (or portions thereof) may be returned, either from shared memory 340 and/or from persistent storage 910 .
  • session object if more than one session request is received for the session object, only the first of them activates the session. While the session object is active, subsequent session requests receive the already-activated object (e.g., either through local memory or through shared memory).
  • a local or “dead” copy of the session object 904 is maintained within the virtual machine 321 when the session is inactivated. Because the session object is dead, it may be garbage collected under certain circumstances (e.g., if memory usage reaches a threshold value). Garbage collection is a well known technique for freeing memory in an object-oriented environment such as Java. However, if a second session request is received at the virtual machine 321 before the dead session object is garbage collected then, in one embodiment, the dead session object 904 may be reused and activated once again (i.e., without retrieving the inactive copy from shared memory).
  • an enterprise application typically consists of a variety of different layers that are managed from different containers (e.g., Web container 540 , EJB container 542 , . . . etc).
  • containers e.g., Web container 540 , EJB container 542 , . . . etc.
  • multiple session objects may be created and managed within each of the different layers.
  • the Web container 540 uses HTTP objects (e.g., javax.servlet.HttpSession objects) to maintain HTTP session data
  • the EJB container 542 uses session beans to maintain the session state of the user.
  • Two general session relations may be defined: (1) explicitly declared session relations in which the relation is created by the container and can be explicitly declared in the session management layer; and (2) implicitly declared session relations in which the relation between sessions is the result of an application's program code. In the latter case, the container processing the request may not be notified that other session objects exist for the currently-processed session.
  • the enterprise portal container 541 is built on top of the Web container 540 , and provides its own session state for the user (e.g., portal objects 520 and 521 ). However, the user is identified from the HTTP session object (e.g., HTTP session 511 ). Thus, to associate the two different types of sessions, the enterprise portal container 541 explicitly declares that the portal session 520 , 520 is joined to the HTTP session 511 .
  • a common example of an implicitly-declared session relation is between an HTTP session 511 and associated EJB sessions within the EJB container 542 .
  • the reference between the HTTP session and EJB session comes into existence when the application creates EJB objects and stores them in the HTTP session.
  • the reference is implicitly involved in the HTTP session as a result of application program code.
  • the session management layer 330 automatically detects implicit references and, once detected, treats the implicit references for session lifecycle management purposes like explicitly declared weak references.
  • the session management layer must provide a mechanism to identify related session data in different session domains.
  • the programming logic is implemented as Servlets or JSPs and session state is stored in different objects called HttpSessions.
  • the session state and the programming logic are unified in one object—the EJB instance.
  • the session state is stored in the fields of the EJB object while the programming logic is implemented in the business methods of the bean.
  • One embodiment of the invention manages the life cycle of each session object using four states: valid, invalid, transparent, and removed. The transitions between each of these states are illustrated in FIG. 10 .
  • the session object is not expired or explicitly invalidated.
  • the valid state includes two sub-states: the active state and the inactive state (described above with respect to FIG. 9 ).
  • the active state the session object is currently being accessed by the application.
  • the session object is stored in the local memory heap where the session is accessed.
  • the inactive state the session is stored in the backend storage or shared memory 340 and should be activated before usage.
  • no client requests are associated with the session.
  • the invalid state 1003 the session is expired or it is explicitly invalidated by the application or container.
  • the session is accessible to be removed from storage (e.g., via the garbage collection process).
  • the session object In the transparent state 1002 , the session object is expired or it is explicitly invalidated, but some other sessions have a reference to it. This is an abstract state where the specific functionality of the session object depends from the containers associated with the session object, as described herein.
  • the removed state 1004 the session object is not available in the system (i.e., it has been removed by the garbage collection process).
  • the “stickiness” of a session object indicates that the session object cannot be shared with other virtual machines (i.e., the object has an affinity to the server process of its virtual machine). As mentioned above, the stickiness is related to the inactive state of the session and is used to determine the possibility to activate the session in other server process (i.e., other virtual machines). Because it cannot be shared, all session requests associated with a sticky session are performed in the same server process.
  • the stickiness of a session object is temporarily defined.
  • the session may be sticky for some time period and may subsequently transition to “non-sticky” (i.e., shareable).
  • transitions between sticky and non-sticky managed by the application In general, a session object is sticky if it references resources which are local to the server instance on which it resides (and, therefore, cannot be migrated to another instance).
  • a particular virtual machine implementation may reference a specific socket connection to a remote server. In this case, the session object would need to run only on the particular virtual machine to be provided with access to the remote socket connection.
  • the stickiness of a session object may also result from specific references to files within the file system/database and specific references to database connections. In sum, any function which cannot be performed outside of the local virtual machine may cause a session object to become “sticky.”
  • the sticky attribute of each object is managed simultaneously for all related sessions.
  • a session which is related to other sessions is sticky if the session itself is sticky or if one of the session objects which references it is sticky. This principle is consistent with the underlying techniques described herein for object sharing across multiple virtual machines (see, description of “shared closures”).
  • session management layer 330 manages the state of a session object based on changes in state of related session objects. A distinction here is made between explicitly declared session's relations and implicitly declared session relations.
  • a session object's relation to other session objects may be declared from session to session.
  • One embodiment of the invention employs three reference types defining the relationships between sessions: strong references, soft references, and weak references.
  • each of the two sessions share the same life cycle. As a result, if one of the sessions goes to the invalid state, then the other session will also go to the invalid state.
  • FIGS. 11 a - b show session a object 1102 within session domain B with a strong reference to a session object 1101 in session domain A.
  • session object 1102 might represent EJB object 501 within the EJB container 542 and session object 1101 might represent HTTP session object 511 within the Web container 540 .
  • the HTTP session object 511 is invalidated, then the related EJB session object 501 should also be invalidated, as shown in FIG. 11 a .
  • the HTTP session object 511 is invalidated, then the related EJB session object 501 should also be invalidated, as shown in FIG. 11 b .
  • session objects that have only strong references cannot be in the “transient” state.
  • the referent session object 1201 (i.e., the session which is referred to) has its own, independent lifecycle from the session object 1202 that refers to it.
  • the lifecycle of the session object 1202 containing the reference follows the lifecycle of the referent session object 1201 (but doesn't influence it).
  • the referent session object 1201 is invalidated, all sessions that have a soft reference to it, such as session object 1202 , will be invalidated, but if any of the other session objects are invalidated, the referent session object 1201 will still remain in the valid state.
  • portal object 520 may have a soft reference to HTTP session object 511 .
  • the HTTP session object 511 is invalidated, then the portal session object 520 that references it is also be invalidated.
  • the portal session object 520 is invalidated (e.g., the end user simply closes a window within a the Web browser), then the HTTP session object 511 should typically remain valid, thereby maintaining the user's HTTP session with the Web server.
  • the session objects 1301 - 1302 have their own, independent life cycle. However, if the referent session object 1201 is invalidated at a time when it is referenced from other valid session objects, it will transition to the transparent state 1002 as illustrated in FIG. 10 . When no valid session objects reference the session object 1201 , it then transitions to the invalid state 1003 .
  • an HTTP session object 511 may have a weak reference to a portal session object 520 representing, e.g., a window within a Web browser.
  • a portal session object 520 representing, e.g., a window within a Web browser.
  • the portal session object 520 will transition to the transparent state if any other session objects refer to it (e.g., other portal objects such as portal session object 521 ).
  • the session management layer 330 detects a reference between one or more sessions that are not explicitly declared, and automatically generates a weak reference between them. In one embodiment, it also marks the weak reference as “automated”—i.e., an additional session attribute used to note that the reference was established automatically from the container. The session management layer uses this attribute to deactivate the session object when container determines that the sessions are no longer connected (e.g., because the other session object has been invalidated). In one embodiment, from a session management point of view, the reference is managed in the same way as an explicitly declared weak reference (described above).
  • the session management layer 330 searches for specific objects in the session content during the inactivation process. The availability of one such object will indicate session dependency.
  • the session representation used in this process is illustrated in FIG. 14 .
  • the client view 1402 is a thin object wrapper providing access to the session data through the SessionRef object 1400 .
  • the session ref is a bridge from client to the session management view of the session.
  • the session management view 1401 of the session is the real session object where the user state is stored.
  • SessionRef object 1400 if the SessionRef object 1400 is found in the content of session data during the inactivation process, then a weak reference between sessions is created. The reference is removed in some of the next inactivation processes if the same SessionRef object is no longer contained in the session.
  • the Java Object Serialization mechanism is used to search for SessionRef objects in the object graph of session content.
  • Embodiments of the invention may include various steps as set forth above.
  • the steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps.
  • these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.
  • Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions.
  • the machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions.
  • the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).

Abstract

A system and method are described for managing session lifecycles within a multi-tiered enterprise network. In one embodiment, a plurality of session objects are generated at different layers of the enterprise network in response to a client request. Each of the session objects store session data defining a state of interaction with the client. In addition, one embodiment of the invention manages the lifecycle of a first session object based on corresponding lifecycles of one or more related session objects and also the type of relationship existing between the first session object and the one or more related session objects. In one embodiment, the defined relationship types include strong references, weak references, and soft references.

Description

BACKGROUND
1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for managing related session lifecycles within an enterprise network.
2. Description of the Related Art
Multi-Tiered Enterprise Computing Systems
Traditional client-server systems employed a two-tiered architecture such as that illustrated in FIG. 1 a. Applications 102 executed on the client side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101. A database 104 maintained on the server 101 provides non-volatile or “persistent” storage for the data accessed and/or processed by the application 102.
The “business logic” component of the application represents the core program code of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1 a become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 1 b. In the multi-tiered system, the presentation logic 121, business logic 122 and database 123 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers on the network 103. For example, the presentation logic 121, the business logic 122, and the database 123 may each be maintained on separate servers, 126, 127 and 128, respectively.
This separation of logical components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
The multi-tiered architecture illustrated in FIG. 1 b may be implemented using a variety of different application technologies at each of the layers of the multi-tier architecture, including those based on the Java ™2 Enterprise Edition (“J2EE™”) standard, the Microsoft .NET standard and/or the Advanced Business Application Programming (“ABAP”) standard developed by SAP AG. For example, as described below, in a J2EE environment, the business layer 122, which handles the core business logic of the application, is comprised of Enterprise Java Bean (“EJB™”) components with support for EJB containers. Within a J2EE environment, the presentation layer 121 is responsible for generating servlets and Java Server Pages (“JSP™”) interpretable by different types of browsers at the user interface layer 120.
J2EE Application Server Architecture
FIG. 2 a illustrates a typical J2EE application server 200 in which the presentation layer is implemented by a “Web container” 211 and the business layer is implemented by an Enterprise Java Bean (“EJB”) container 201. Containers are runtime environments which provide standard common services 219, 209 to runtime components. For example, the Java Naming and Directory Interface (“JNDI”) is a service that provides application components with methods for performing standard naming and directory services. Containers also provide unified access to enterprise information systems 217 such as relational databases through the Java Database Connectivity (“JDBC”) service, and legacy computer systems through the J2EE Connector Architecture (“JCA”) service. In addition, containers provide a declarative mechanism for configuring application components at deployment time through the use of deployment descriptors.
As illustrated in FIG. 2 a, each layer of the J2EE architecture includes multiple containers. The Web container 211, for example, is itself comprised of a servlet container 215 for processing servlets and a Java Server Pages (“JSP”) container 216 for processing Java server pages. The EJB container 201 includes three different containers for supporting three different types of enterprise Java beans: a session bean container 205 for session beans, a entity bean container 206 for entity beans, and a message driven bean container 207 for message driven beans. A more detailed description of J2EE containers and J2EE services can be found in RAGAE GHALY AND KRISHNA KOTHAPALLI, SAMS TEACH YOURSELF EJB IN 21 DAYS (2003) (see, e.g., pages 353-376).
Session Management
An application server 200 manages “session data” associated with each client interaction. The session data defines the current conversational state between the client and the application server. For example, if the user is purchasing books from an online bookstore, the session data may define the current state of the user's “shopping cart” (e.g., the books the user has selected for purchase). Similarly, if the user is logged in to a particular Web portal (e.g., “My Yahoo”), the session data may define the state of the Web pages opened in the user's Web browser.
Different types of session data are maintained at each logical layer of the application server 200. For example, referring to FIG. 2 b, in response to a single client 230 request from a Web browser, an HTTP session object 241 (e.g., an instance of javax.servlet.HttpSession) containing HTTP session data is managed within the Web container 240 and (depending on the type of application) multiple session beans 251-253 may be managed within the EJB container 250 . Additional HTTP session objects 242 and session beans 254-255 may be managed concurrently to define the conversational state with additional clients 231 for the same application (e.g., the shopping cart application) or other applications (e.g., a “search” application). Thus, the state of any given set of applications such as the user's shopping cart may be spread across multiple containers.
SUMMARY
A system and method are described for managing session lifecycles within a multi-tiered enterprise network. In one embodiment, a plurality of session objects are generated at different layers of the enterprise network in response to a client request. Each of the session objects store session data defining a state of interaction with the client. In addition, one embodiment of the invention manages the lifecycle of a first session object based on corresponding lifecycles of one or more related session objects and also the type of relationship existing between the first session object and the one or more related session objects. In one embodiment, the defined relationship types include strong references, weak references, and soft references.
BRIEF DESCRIPTION OF THE DRAWINGS
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
FIG. 1 a illustrates a traditional two-tier client-server architecture.
FIG. 1 b illustrates a prior art multi-tier client-server architecture.
FIG. 2 a illustrates a multi-tiered application server architecture according to the Java 2 Enterprise Edition (“J2EE”) standard.
FIG. 2 b illustrates different types of session data maintained within a multi-tiered enterprise architecture.
FIG. 3 illustrates a cluster architecture employed in one embodiment of the invention.
FIG. 4 illustrates a session domain hierarchy according to one embodiment of the invention.
FIG. 5 illustrates an exemplary set of related session data managed at various different layers of an enterprise architecture.
FIGS. 6 a-c illustrate session domain hierarchies associated with the exemplary set of session data shown in FIG. 5.
FIG. 7 illustrates a session domain according to one embodiment of the invention.
FIG. 8 illustrates a session object according to one embodiment of the invention that includes a system part and a separate user part.
FIG. 9 illustrates a shared memory implementation of one embodiment of the invention.
FIG. 10 illustrates state transitions for session objects implemented in one embodiment of the invention.
FIG. 11 illustrates one embodiment for managing session objects having strong references.
FIG. 12 illustrates one embodiment for managing session objects having soft references.
FIG. 13 illustrates one embodiment for managing session objects having weak references.
FIG. 14 illustrates a session representation used in one embodiment of the invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Described below is a system and method for managing session lifecycles within a multi-tiered enterprise network. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.
An Exemplary Cluster Architecture
A system architecture according to one embodiment of the invention is illustrated in FIG. 3. The architecture includes a plurality of application server instances 301 and 302. The application server instances 301 and 302 each include a group of worker nodes 212-314 and 315-316, respectively, and a request handler 311 and 312, respectively. The application server instances 301, 302 communicate through a central services instance 300 using message passing. In one embodiment, the central services instance 300 includes a locking service and a messaging service (described below). The combination of all of the application server instances 301 and 302 and the central services instance 300 is referred to herein as a “cluster.” Although the following description will focus solely on instance 301 for the purpose of explanation, the same principles apply to other instances within the cluster.
The worker nodes 312-314 within instance 301 provide the business and/or presentation logic for the network applications supported by the system. Each of the worker nodes 312-314 within a particular instance may be configured with a redundant set of application logic and associated data, represented as virtual machines 321-323 in FIG. 3. In one embodiment, the request handler 311 distributes service requests from clients to one or more of the worker nodes 312-314 based on the load on each of the servers. For example, in one embodiment, the request handler maintains separate queues for each of the 312-314 in shared memory 340. The request handler 311 fills the queues with client requests and the worker nodes 312-314 consume the requests from each of their respective queues.
The worker nodes 312-314 may be Java 2 Enterprise Edition (“J2EE”) worker nodes which support Enterprise Java Bean (“EJB”) components and EJB containers (at the business layer) and Servlets and Java Server Pages (“JSP”) (at the presentation layer). In this embodiment, the virtual machines 321-325 implement the J2EE standard (as well as the additional non-standard features described herein). It should be noted, however, that the embodiments of the invention described herein may be implemented in the context of various different software platforms including, by way of example, Microsoft .NET platforms and/or the Advanced Business Application Programming (“ABAP”) platforms developed by SAP AG, the assignee of the present application.
In one embodiment, communication and synchronization between each of the instances 301, 302 is enabled via the central services instance 300. As mentioned above, the central services instance 300 includes a messaging service and a locking service. The message service allows each of the servers within each of the instances to communicate with one another via a message passing protocol. For example, messages from one server may be broadcast to all other servers within the cluster via the messaging service (e.g., such as the cache configuration messages described below). Alternatively, messages may be addressed directly to specific servers within the cluster (i.e., rather than being broadcast to all servers). In one embodiment, the locking service disables access to (i.e., locks) certain specified portions of configuration data and/or program code stored within a central database 345. The locking service locks data on behalf of various system components which need to synchronize access to specific types of data and program code. In one embodiment, the central services instance 300 is the same central services instance as implemented within the Web Application Server version 6.3 developed by SAP AG. However, the underlying principles of the invention are not limited to any particular type of central services instance.
In one embodiment, a session management layer 330 is executed within each of the instances 301-302. The session management layer 330 is comprised of the program code, interfaces and data for implementing the various session management techniques described herein. For example, one embodiment of the session management layer 330 manages session objects within session domains as described in detail below (see, e.g., FIG. 4 and associated text).
In addition, unlike prior systems, one embodiment of the invention shares objects across virtual machines 321-325. Specifically, in one embodiment, objects such as session objects which are identified as “shareable” are stored within a shared memory region 340, 341 and are made accessible to multiple virtual machines 321-325. Creating new object instances from scratch in response to client requests can be a costly process, consuming processing power and network bandwidth. As such, sharing objects between virtual machines as described herein improves the overall response time of the system and reduces server load.
In a shared memory implementation, a shared memory area 340, 341 or “heap” is used to store data objects that can be accessed by multiple virtual machines 321-325. The data objects in a shared memory heap should generally not have any pointers or references into any private heap (e.g., the private memory regions/heaps of the individual virtual machines). This is because if an object in the shared memory heap had a member variable with a reference to a private object in one particular virtual machine, that reference would be invalid for all the other virtual machines that use that shared object.
More formally, this restriction can be thought of as follows: For every shared object, the transitive closure of the objects referenced by the initial object should only contain shared objects at all times. Accordingly, in one implementation of the server 200, objects are not put into the shared memory heap by themselves—rather, objects (such as the session objects described herein) are put into the shared memory heap in groups known as “shared closures.” A shared closure is an initial object plus the transitive closure of all the objects referenced by the initial object.
Session Management Within a Multi-Tiered Enterprise Network
A. Common Session Management
As described above with respect to FIG. 2 b, multiple related session objects may be managed within different tiers of an application server in response to a single client request, or series of client requests. Moreover, a single application may support several concurrent client sessions, resulting in several sets of session objects for each client.
One embodiment of the session management layer 330 employs a hierarchical structure for storing different types of related session data within each enterprise application (e.g., HTTP sessions, session EJBs, etc). In particular, as illustrated in FIG. 4, one embodiment of the session management layer groups related session objects within a logical hierarchy. At the top of the hierarchy is a session context object 400. “Session domains” are the base configurable objects within the session hierarchy and are positioned beneath the session context 400. The session domains represent abstract storage units for sessions that have similar characteristics (e.g., similar life cycles, applications, etc).
In the example shown in FIG. 4, session objects 411 and 412 are managed within session domain 410, and session objects 421 and 422 are managed within session domain 420. Both session domains 410 and 420 are positioned directly beneath the session context 400. In one embodiment, each session domain 410 and 420 contains session objects related to different applications. For example, session domain 410 may contain session objects related to a “shopping cart” application and session domain 420 may contain session objects related to a “calculator” application.
Two additional session domains 430 and 440 are logically positioned beneath session domain 410 within the hierarchy. In one embodiment, these session domains 430 and 440 include session objects 431, 432 and 441, 442, respectively, from the same application associated with session domain 410. Returning to the previous example, if session domain 410 is associated with a shopping cart application, session domains 430 and 440 include session objects related to the shopping cart application.
Grouping session objects for an application within the same session domain provides a consistent, logical way to manage session data. For example, as describe below with respect to FIG. 7, different session policy and configuration parameters may be applied to each session domain such as, for example, session timeout periods and different storage implementations (e.g., shared memory, persistent storage, . . . etc).
In one embodiment, a different session context 400 and associated hierarchy of session domains is maintained by the session management layer 330 for each layer of the application server. This embodiment will be described using the example illustrated in FIG. 5 in which a plurality of session objects are managed for two different applications, identified as applications “A” and “B.” The conversational state between client 530 and application A is maintained via three session bean objects 501-503 within the EJB container 542; an HTTP session object 511 within the Web container 540; and two portal session objects 520-521 within the enterprise portal container. Similarly, the conversational state between client 531 and application A is maintained via two session bean objects 504, 506, one HTTP session object 512, and one portal session object 522. Finally, the conversational state between client 532 and application B is maintained via two session bean objects 507-508, one HTTP session object 513, and one portal session object 523.
In the illustrated example, session bean objects 501 and 504 are instances of a particular session bean, “EJB A,” and session bean objects 502 and 506 are instances of another session bean, EJB B. Session bean objects 503, 507 and 508 are instances of session beans C, D and E, respectively.
In one embodiment, the enterprise portal container 541 is built on top of the Web container 540. As illustrated, a single HTTP session object 511 may be related to multiple portal session objects 521, 521, which store user-specific session data for a plurality of user-specific Web content (e.g., Web pages) generated during the session. When a user logs in to a Web server, for example, multiple user-specific Web pages may be generated in response to client requests and opened in different windows of the client's Web browser. Thus, a single HTTP session object 511 is managed within the Web container 540 and separate portal session data related for each individual window of the user's browser is stored within the portal session objects 520-521. Said another way, the HTTP session object 511 manages session data related to the entire user session with the application server, whereas the portal session objects store session data for specific pages generated during the session (e.g., “My Yahoo” pages on the “Yahoo” Website).
As illustrated in FIGS. 6 a-c, each different type of session object shown in FIG. 5 is managed within a session domain under a different context. For example, as illustrated in FIG. 6 a, separate session domains 610 and 620, are maintained for applications A and B, respectively, under session bean context 600. A separate EJB session domain is used to store and manage session instances for each session bean of each application. For example, under the application A session domain 610, session domain 630 associated with EJB A stores session objects 501, 504 which are instances of session bean A; session domain 640 associated with EJB B stores session objects 502, 506 which are instances of session bean B; and session domain 650 associated with EJB C stores session objects 503 which are instances of session bean C. Similarly, under the application B session domain 620, session domain 660 associated with EJB D stores session objects 507 which are instances of session bean D, and session domain 670 associated with EJB E stores session objects 508 which are instances of session bean E. Thus, all session beans are managed under the same session bean context 600 and grouped under application-specific and bean-specific session domains, thereby simplifying the management and configuration of similar session objects.
As illustrated in FIG. 6 b, separate HTTP session domains 611 and 621 associated with applications A and B, respectively, are managed under an HTTP session context 601. The HTTP session domains store session data associated with each applications' HTTP sessions. For example, HTTP session objects 511 and 512 are stored within the session domain 611 for application A, and HTTP session object 513 is stored within the session domain 621 for application B.
In addition, in one embodiment, illustrated in FIG. 6 c, separate portal session domains 612 and 622 associated with applications A and B, respectively, are managed under an application portal session context 602. The portal session domains store portal session objects containing portal data associated with each application. Specifically, portal session objects 520-522 are stored under the portal session domain 612 for application A, and portal session object 523 is stored under the session domain 622 for application B.
FIG. 7 illustrates additional details related to the configuration of each session domain 700 according to one embodiment of the invention. Specifically, each session domain 700 includes a set of configuration policy objects 703, a set of local storage attributes 702 and a set of global storage attributes 701.
The configuration policy objects 703 define the behavior of each session domain. In one embodiment, the configuration policies implemented by the policy objects include, but are not limited to, a “thresholds” policy for setting limits on the number of sessions objects which are stored within each domain. For example, one session object may be joined to one or more session requests based on the thresholds policy. In addition, In one embodiment, a session access policy is implemented which allows the application or other entity which created the session domain (the “domain owner”) to restrict or otherwise influence session access. For example, the domain owner may prevent multithreaded session access via the session access policy. In one embodiment, the configuration policy 703 further includes a session invalidation policy which defines the behavior of the session object in the case of session invalidation. For example, as described in greater detail below, in one embodiment, transparent session objects are employed under certain conditions. Moreover, inactive sessions may be stored to persistent storage (e.g., the database or file system) and reactivated at a later time in response to subsequent requests.
In one embodiment, a persistence policy is also implemented within the configuration policy objects 703 to define whether persistent storage should be used and, if so, the particular type of persistent storage that should be used. Session persistence types may include, but are not limited to, in-memory session persistence (i.e., session objects within the domain are stored within the memory of a single process); in-memory replication persistence (i.e., session object state is stored within a server process memory and is replicated to other server processes); database-based persistence (i.e., the session objects are stored in the database and may be shared across server processes); file system persistence (i.e., sessions are stored within a directory of the file system and can be shared across processes); and cookie-based persistence (i.e., session data is stored within the client in a cookie). It should be noted, however, that the underlying principles of the invention are not limited to any particular set of configuration properties.
Returning to FIG. 7, the global storage attributes 701 of each session domain 700 define attributes of the session domain which are shared across different virtual machines (e.g., different instances of the session domain implemented on different virtual machines). For example, the global session attributes may specify that all sessions within the particular domain 700 have the same expiration time (e.g., become inactive/invalid after a period of non-responsiveness from a client). By way of another example, EJB application descriptors may be parsed once and shared between each of the EJB domains located under the session bean context 600, and Web application descriptors may be parsed only once and shared between each of the session objects located under the HTTP session context 601. In one embodiment, global storage attributes are used only in a shared memory implementation (i.e., in which virtual machines 321-325 share session objects via shared memory 340-341 as described herein). In one embodiment, global attributes are identified in shared memory using a unique global attribute name.
The local storage attributes 702 of the session domain define session attributes which are specific to each individual virtual machine (i.e., they are container-specific). For example, if a particular virtual machine relies on a socket connection to a particular remote server, then this information may be provided within the local storage attributes. Local storage attributes may also include specific references to files within the file system/database and specific references to database connections. In an embodiment which does not employ a shared memory implementation, all attributes of the session domain 700 are stored within the local storage attributes 702.
The different containers can use the local storage attributes 702 to keep certain attributes banded to each concrete server process. For example the HttpSession includes the method javax.servlet.ServletContext getServletContext ( ). However, ServletContext can not be shared between different virtual machines because it maintains references to different resources that are local for the concrete server process. Thus, to enable the application to retrieve the ServletContext from the HttpSession, the Web container binds the ServletContext as a local attribute for the session domain. The getServletContext( ) method is implemented to provide a lookup of this attribute from the SessionDomain. Using this technique, the getServletContext( ) will return different objects based on the server process where the session is activated.
As illustrated in FIG. 8, in one embodiment of the invention, each session object 710 is logically separated into two different sub-parts or sub-objects: a system object 801 for storing system session data and a user object 802 for storing user session data. The system object 801 includes data used by the application container 820 for session identification and session life cycle management (described in greater detail below). For example, the system object 801 includes the time that the session was created and the last time the session was accessed. The application container reads this information to determine whether the session object 710 should move from a valid to an invalid (active state is the state when we have requests to the session) state (e.g., if it has not been accessed by an application for an extended period of time). The system object 801 also includes system data indicating whether the session object is to be stored in persistent storage (e.g., the database or file system) and/or shared memory (e.g., whether the session object is non-shareable or “sticky”), the state of the session (e.g., valid, invalid, transparent, removed), and the session domain ID.
The user object 802 includes user data typically accessed by applications 810 (rather than by the container). This may include, for example, user-specific session data for a particular Web page and/or data related to the current state of the user's browser. In one embodiment, all attributes stored in the HttpSession from the application are stored in the user object. In addition, the instances of each statefull EJB object may also be stored in the user object.
One embodiment of the session management layer 330 relies on the separation between system and user data to improve the efficiency with which the container and/or application accesses the session data. The system object 801 is typically much smaller in size than the user object 802 and is not modified very frequently (although it may be accessed frequently). Thus, in one embodiment, the system object 801 is optimized for read access. For example, the system object 801 may be cached in main memory (shared memory 330 and/or local memory within the server on which the VM is executed) rather than being stored in persistent storage.
By contrast, the user object 802, which is significantly larger than the system object 801, may be stored to persistent storage. In one embodiment, to improve the efficiency with which user session data is accessed from persistent storage, the user session data is separated in the one or more independently-accessible parts called “delta attributes.” Because each of the delta attributes can be read independently from other attributes the entire block of system data does not need to be read to retrieve a particular attribute, thereby further improving efficiency. In one embodiment, the delta attributes represent the changes in the user data since the last time the user object was accessed. Reading only changes in the user data rather than all of the user data further improves access time.
In one embodiment, the delta attributes are stored/retrieved in the session using addDelta/getDelta methods of the Session. Any attribute of an object can be stored as a delta attribute in the session object. In one embodiment, the delta attributes are not read from the backend store when the session is activated. Rather, the delta attributes are read only when the client attempts to retrieve them using the getDelta( ) method.
As indicated in FIG. 8, to access session data from the session object 710, both the container 820 and applications 810 generate a session request, identifying the session by its name. In one embodiment, the session management layer 330 maintains a name-object mapping (e.g., within a mapping table) to identify the session object 710 using its name. Once the session object 710 is identified, the session management layer 330 determines which portion of the session object to provide to the requestor based on the type of requestor. For example, in response to session requests from the container 820, the session management layer 330 provides system data from within the system data object 801, whereas in response to session requests from applications 810, the session management layer 330 provides user data from the user data object 802. Thus, in this embodiment, the mechanism for retrieving the correct set of data is transparent to the requester. Of course, in an alternate embodiment, the container 820 and applications 810 may directly access the system data 801 and user data 802, respectively.
In one embodiment of the invention, session objects are managed differently depending on the objects' state. For example, “active” session objects generated in response to a session request are maintained within the local memory (or “heap”) of the virtual machine in which the session request originated. However, in a shared memory implementation, when a session object becomes inactive (e.g., due to a lack of interaction with the requestor), it is transferred to shared memory 340-341 so that it may be reused by other virtual machines. Thus, at any given time, session objects 710 from a particular session domain 700 may be stored in local memories of each virtual machine and/or the shared memory (and/or persistent storage). In one embodiment, each session domain 700 is logically separated into a local portion which contains active sessions, and a shared portion, which contains inactive sessions. In a non-shared memory implementation, persistent storage such as the database or file system may be used to store inactive session objects in an analogous manner.
As used herein, an “active” session is one which is currently in use by the application and can be modified. The runtime representation contains all fields and members of the session object, which are directly accessible by the application. In “inactive” session object is one which is not currently being used by the application. Inactive session object are prepared to be written to shared memory and/or persistent storage in their serialized and/or shareable form, respectively. These session objects may be provided with additional member values used to restore the original state of the object after copying from shared memory or deserialization from persistent storage.
For the purpose of illustration, a transaction involving a particular session object is illustrated generally in FIG. 9. In response to a first session request, an active session object 901 is generated within virtual machine 321 . The session object may then be modified in its active state, resulting in a modified active session object 903. The modified active session object 903 eventually changes state to an inactive session object 902 which is stored within shared memory 340 in a shared memory implementation. Alternatively, in a non-shared memory implementation, the inactive session object 902 may be serialized and stored within the database and/or file system 910, or simply stored within the local memory heap.
Once the inactive session is stored in shared memory, it may be accessed from any virtual machine. For example, in FIG. 9, a second session request is illustrated in both virtual machine 321 and virtual machine 322. In response to either request, the inactive session object is activated and copied back to the virtual machine where the second request originated. The session object may then be accessed and modified again, as described herein. For example, in response to a container session request, only the system data portion 801 of the session object may be accessed, whereas, in response to an application session request, the user data portion 802 of the session object (or portions thereof) may be returned, either from shared memory 340 and/or from persistent storage 910.
In one embodiment, if more than one session request is received for the session object, only the first of them activates the session. While the session object is active, subsequent session requests receive the already-activated object (e.g., either through local memory or through shared memory).
As illustrated in FIG. 9, in one embodiment, a local or “dead” copy of the session object 904 is maintained within the virtual machine 321 when the session is inactivated. Because the session object is dead, it may be garbage collected under certain circumstances (e.g., if memory usage reaches a threshold value). Garbage collection is a well known technique for freeing memory in an object-oriented environment such as Java. However, if a second session request is received at the virtual machine 321 before the dead session object is garbage collected then, in one embodiment, the dead session object 904 may be reused and activated once again (i.e., without retrieving the inactive copy from shared memory).
B. Common Session Lifecycle Management
As described above with respect to FIG. 5, an enterprise application typically consists of a variety of different layers that are managed from different containers (e.g., Web container 540, EJB container 542, . . . etc). In response to a single client request, multiple session objects may be created and managed within each of the different layers. For example, in a Java environment, the Web container 540 uses HTTP objects (e.g., javax.servlet.HttpSession objects) to maintain HTTP session data whereas the EJB container 542 uses session beans to maintain the session state of the user.
Session Relationships
Different types of dependencies exist between the session objects within managed within each of the different layers. In one embodiment of the invention, to maintain consistency of user sessions that depend one another, related sessions are managed at a whole. Two general session relations may be defined: (1) explicitly declared session relations in which the relation is created by the container and can be explicitly declared in the session management layer; and (2) implicitly declared session relations in which the relation between sessions is the result of an application's program code. In the latter case, the container processing the request may not be notified that other session objects exist for the currently-processed session.
As an example of an explicitly declared session, the enterprise portal container 541 is built on top of the Web container 540, and provides its own session state for the user (e.g., portal objects 520 and 521). However, the user is identified from the HTTP session object (e.g., HTTP session 511). Thus, to associate the two different types of sessions, the enterprise portal container 541 explicitly declares that the portal session 520, 520 is joined to the HTTP session 511.
A common example of an implicitly-declared session relation is between an HTTP session 511 and associated EJB sessions within the EJB container 542. In this case, the reference between the HTTP session and EJB session comes into existence when the application creates EJB objects and stores them in the HTTP session. Thus, the reference is implicitly involved in the HTTP session as a result of application program code. As described in greater detail below, in one embodiment of the invention, the session management layer 330 automatically detects implicit references and, once detected, treats the implicit references for session lifecycle management purposes like explicitly declared weak references.
Because of the different programming models (i.e., HTTP session state is separated from programming logic, whereas the EJB state is part of the logic) the session management layer must provide a mechanism to identify related session data in different session domains. In Web applications, the programming logic is implemented as Servlets or JSPs and session state is stored in different objects called HttpSessions. In the EJB session model, the session state and the programming logic are unified in one object—the EJB instance. In this model, the session state is stored in the fields of the EJB object while the programming logic is implemented in the business methods of the bean.
Session Life Cycles
One embodiment of the invention manages the life cycle of each session object using four states: valid, invalid, transparent, and removed. The transitions between each of these states are illustrated in FIG. 10.
In the valid state 1001 the session object is not expired or explicitly invalidated. In this state the session object is accessible from the application. The valid state includes two sub-states: the active state and the inactive state (described above with respect to FIG. 9). In the active state, the session object is currently being accessed by the application. As described above, in the active state, the session object is stored in the local memory heap where the session is accessed. In the inactive state the session is stored in the backend storage or shared memory 340 and should be activated before usage. In this state, no client requests are associated with the session. In the invalid state 1003 the session is expired or it is explicitly invalidated by the application or container. In this state, the session is accessible to be removed from storage (e.g., via the garbage collection process). In the transparent state 1002, the session object is expired or it is explicitly invalidated, but some other sessions have a reference to it. This is an abstract state where the specific functionality of the session object depends from the containers associated with the session object, as described herein. In the removed state 1004, the session object is not available in the system (i.e., it has been removed by the garbage collection process).
Session Stickiness
The “stickiness” of a session object indicates that the session object cannot be shared with other virtual machines (i.e., the object has an affinity to the server process of its virtual machine). As mentioned above, the stickiness is related to the inactive state of the session and is used to determine the possibility to activate the session in other server process (i.e., other virtual machines). Because it cannot be shared, all session requests associated with a sticky session are performed in the same server process.
In one embodiment, the stickiness of a session object is temporarily defined. The session may be sticky for some time period and may subsequently transition to “non-sticky” (i.e., shareable). In one embodiment, transitions between sticky and non-sticky managed by the application. In general, a session object is sticky if it references resources which are local to the server instance on which it resides (and, therefore, cannot be migrated to another instance). For example, a particular virtual machine implementation may reference a specific socket connection to a remote server. In this case, the session object would need to run only on the particular virtual machine to be provided with access to the remote socket connection. The stickiness of a session object may also result from specific references to files within the file system/database and specific references to database connections. In sum, any function which cannot be performed outside of the local virtual machine may cause a session object to become “sticky.”
In one embodiment, in order to maintain a consistent user session state spread over several containers, the sticky attribute of each object is managed simultaneously for all related sessions. As a general rule, a session which is related to other sessions is sticky if the session itself is sticky or if one of the session objects which references it is sticky. This principle is consistent with the underlying techniques described herein for object sharing across multiple virtual machines (see, description of “shared closures”).
Managing Session's Relationships
One embodiment of the session management layer 330 manages the state of a session object based on changes in state of related session objects. A distinction here is made between explicitly declared session's relations and implicitly declared session relations.
Explicitly Declared Relations
A session object's relation to other session objects may be declared from session to session. One embodiment of the invention employs three reference types defining the relationships between sessions: strong references, soft references, and weak references.
In one embodiment of the invention, if one of two sessions has a “strong” reference to the other of the two sessions, then each of the two sessions share the same life cycle. As a result, if one of the sessions goes to the invalid state, then the other session will also go to the invalid state.
This is illustrated in FIGS. 11 a-b which show session a object 1102 within session domain B with a strong reference to a session object 1101 in session domain A. As an example, session object 1102 might represent EJB object 501 within the EJB container 542 and session object 1101 might represent HTTP session object 511 within the Web container 540. In this case, if the HTTP session object 511 is invalidated, then the related EJB session object 501 should also be invalidated, as shown in FIG. 11 a. Conversely, if the HTTP session object 511 is invalidated, then the related EJB session object 501 should also be invalidated, as shown in FIG. 11 b. Obviously, session objects that have only strong references cannot be in the “transient” state.
Referring now to FIGS. 12 a-b, in the case of a “soft” reference, the referent session object 1201 (i.e., the session which is referred to) has its own, independent lifecycle from the session object 1202 that refers to it. By contrast, the lifecycle of the session object 1202 containing the reference follows the lifecycle of the referent session object 1201 (but doesn't influence it). Thus, if the referent session object 1201 is invalidated, all sessions that have a soft reference to it, such as session object 1202, will be invalidated, but if any of the other session objects are invalidated, the referent session object 1201 will still remain in the valid state.
For example, referring again to FIG. 5, portal object 520 may have a soft reference to HTTP session object 511. As a result, if the HTTP session object 511 is invalidated, then the portal session object 520 that references it is also be invalidated. However, if the portal session object 520 is invalidated (e.g., the end user simply closes a window within a the Web browser), then the HTTP session object 511 should typically remain valid, thereby maintaining the user's HTTP session with the Web server.
As illustrated in FIGS. 13 a-b, in the case of a “weak” reference, the session objects 1301-1302 have their own, independent life cycle. However, if the referent session object 1201 is invalidated at a time when it is referenced from other valid session objects, it will transition to the transparent state 1002 as illustrated in FIG. 10. When no valid session objects reference the session object 1201, it then transitions to the invalid state 1003.
By way of another example, an HTTP session object 511 may have a weak reference to a portal session object 520 representing, e.g., a window within a Web browser. As a result, if the HTTP session object 511 is invalidated, the portal session object 520 will transition to the transparent state if any other session objects refer to it (e.g., other portal objects such as portal session object 521).
Implicitly Declared Relations
In one embodiment of the invention, if the session management layer 330 detects a reference between one or more sessions that are not explicitly declared, and automatically generates a weak reference between them. In one embodiment, it also marks the weak reference as “automated”—i.e., an additional session attribute used to note that the reference was established automatically from the container. The session management layer uses this attribute to deactivate the session object when container determines that the sessions are no longer connected (e.g., because the other session object has been invalidated). In one embodiment, from a session management point of view, the reference is managed in the same way as an explicitly declared weak reference (described above).
To automatically detect session dependencies, one embodiment of the session management layer 330 searches for specific objects in the session content during the inactivation process. The availability of one such object will indicate session dependency. The session representation used in this process is illustrated in FIG. 14. The client view 1402 is a thin object wrapper providing access to the session data through the SessionRef object 1400. The session ref is a bridge from client to the session management view of the session. The session management view 1401 of the session is the real session object where the user state is stored.
In one embodiment, if the SessionRef object 1400 is found in the content of session data during the inactivation process, then a weak reference between sessions is created. The reference is removed in some of the next inactivation processes if the same SessionRef object is no longer contained in the session. In one embodiment, the Java Object Serialization mechanism is used to search for SessionRef objects in the object graph of session content.
Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.
Certain embodiments described above operate in a shared memory environment. Additional details related to object sharing may be found in, for example, U.S. patent application Ser. No. 10/851,795 entitled “Sharing Objects in Runtime Systems,” filed on May 20, 2004, which is assigned to the assignee of the present application.
Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, although many of the embodiments set forth above relate to a Java or J2EE implementation, the underlying principles of the invention may be implemented in virtually any enterprise networking environment. Moreover, although some of the embodiments set forth above are implemented within a shared memory environment, the underlying principles of the invention are equally applicable to a non-shared memory environment.
Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.

Claims (17)

1. A method comprising:
generating a plurality of related session objects in response to a client request, the plurality of related session objects storing session data defining a state of interaction with the client, the plurality of related session objects instantiated within an application server;
managing the lifecycle of a first session object of the plurality of related session objects, the first session object located within a first logical layer of the application server, based on corresponding lifecycles of one or more other session objects of the plurality of related session objects and the type of relationship existing between the first session object and the one or more other session objects of the plurality of related session objects.
2. The method as in claim 1 wherein the first session object is located within a different layer of the application server than at least one of the one or more other session objects of the plurality of related session objects.
3. The method as in claim 2 wherein the first session object is within a Web container and a second session object of the plurality of related session objects is within a business layer implemented within a managed runtime environment.
4. The method of claim 1, wherein a relationship between the first session object and the one or more other session objects of the plurality of related session objects is defined explicitly by a session management layer, the session management layer is a logical layer within the application server.
5. The method of claim 1, wherein a relationship between the first session object and the one or more other session objects of the plurality of related session objects is defined implicitly by a programming code of an application.
6. The method of claim 1, wherein the managing of the lifecycle of the first session object includes invalidating the first session object in response to the invalidation of a second session object,
wherein the first session object maintains a strong reference type of relationship to the second session object, and
wherein the strong reference type of relationship between objects defines a relationship where the objects share the same lifecycle.
7. The method of claim 6, wherein the managing of the lifecycle of the first session object includes invalidating the second session object in response to the invalidation of the first session object.
8. The method of claim 1, wherein the managing of the lifecycle of the first session object includes invalidating the first session object in response to the invalidation of a second session object,
wherein the first session object maintains a soft reference type of relationship to the second session object, and
wherein the soft reference type of relationship between objects defines a relationship where the lifecycle of the first session object maintaining the soft reference is based on the lifecycle of the object the soft reference is pointing to.
9. The method of claim 8, wherein the managing the lifecycle of the first session object includes maintaining the second object in a valid state based on the first session object being invalidated.
10. The method of claim 1, wherein the managing the lifecycle of the first session object includes maintaining an invalidated second object in a transparent state,
wherein the first session object maintains a weak reference type of relationship to the second session object, and
wherein the weak reference type of relationship between objects defines a relationship where the object being referred to by the weak reference is maintained so long as at least one valid object maintains a weak reference to the object.
11. The method of claim 10, wherein the managing of the lifecycle of the first session object includes removing the second session object in response to the first session object being invalidated, and
wherein none of the plurality of related session objects maintains any type of relationship with the second session object.
12. The method of claim 1, wherein the lifecycle of the first session object can include the following states, valid, invalid, transparent, and removed, wherein the first session object is in one of the listed states at a time during the lifecycle of the first session object.
13. A machine-readable storage device having program code stored thereon which, when executed by a machine, causes the machine to perform the operations of:
generating a plurality of related session objects in response to a client request, the plurality of related session objects storing session data defining a state of interaction with the client, the plurality of related session objects instantiated within an application server;
managing the lifecycle of a first session object of the plurality of related session objects, located within a first logical layer of the application server, based on corresponding lifecycles of one or more other session objects of the plurality of related session objects and the type of relationship existing between the first session object and the one or more other session objects of the plurality of related session objects.
14. The machine-readable storage device as in claim 13 wherein the first session object is located within a different layer of the application server than at least one of the one or more other session objects of the plurality of related session objects.
15. The machine-readable store device as in claim 14 wherein the first session object is within a Web container and a second session object of the plurality of related session objects is within a business layer implemented within a managed runtime environment.
16. A system comprising:
a processor; and
a memory for storing program code which, when executed by the processor, causes the processor to perform the operations of:
generating a plurality of related session objects in response to a client request, the plurality of related session objects storing session data defining a state of interaction with the client, the plurality of related session objects instantiated within an application server;
managing the lifecycle of a first session object of the plurality of related session objects, located within a first logical layer of the application server, based on corresponding lifecycles of one or more other session objects of the plurality of related session objects and the type of relationship existing between the first session object and the one or more other session objects of the plurality of related session objects.
17. A system comprising:
means for generating a plurality of related session objects in response to client requests, the plurality of related session objects storing session data defining a state of interaction with each of a respective plurality of clients, the plurality of related session objects instantiated within an application server;
means for managing the lifecycle of a first session object of the plurality of related session objects, based on corresponding lifecycles of one or more related session objects and the type of relationship existing between the first session object and the plurality of related session objects.
US11/025,549 2004-12-28 2004-12-28 Session lifecycle management within a multi-tiered enterprise network Active 2030-04-19 US8281014B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/025,549 US8281014B2 (en) 2004-12-28 2004-12-28 Session lifecycle management within a multi-tiered enterprise network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/025,549 US8281014B2 (en) 2004-12-28 2004-12-28 Session lifecycle management within a multi-tiered enterprise network

Publications (2)

Publication Number Publication Date
US20060155756A1 US20060155756A1 (en) 2006-07-13
US8281014B2 true US8281014B2 (en) 2012-10-02

Family

ID=36654509

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/025,549 Active 2030-04-19 US8281014B2 (en) 2004-12-28 2004-12-28 Session lifecycle management within a multi-tiered enterprise network

Country Status (1)

Country Link
US (1) US8281014B2 (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120284725A1 (en) * 2009-07-28 2012-11-08 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and Method for Processing Events in a Telecommunications Network
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US20130332618A1 (en) * 2012-06-08 2013-12-12 International Business Machines Corporation Enabling different client contexts to share session information
US8762547B2 (en) 2005-04-29 2014-06-24 Sap Ag Shared memory implementations for session data within a multi-tiered enterprise network
US8799359B2 (en) 2004-12-28 2014-08-05 Sap Ag Session management within a multi-tiered enterprise network
US20150134723A1 (en) * 2013-11-11 2015-05-14 Microsoft Corporation Geo-distributed disaster recovery for interactive cloud applications
US9922088B2 (en) 2013-12-31 2018-03-20 Sybase, Inc. Cardinality estimation using spanning trees
US11086776B2 (en) * 2018-08-29 2021-08-10 International Business Machines Corporation Maintaining correctness of pointers from a managed heap to off-heap memory
US11153319B2 (en) * 2015-10-21 2021-10-19 Okta, Inc. Flexible implementation of user lifecycle events for applications of an enterprise

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060143256A1 (en) 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US8015561B2 (en) * 2004-12-28 2011-09-06 Sap Ag System and method for managing memory of Java session objects
US8281014B2 (en) 2004-12-28 2012-10-02 Sap Ag Session lifecycle management within a multi-tiered enterprise network
US20060248283A1 (en) * 2005-04-29 2006-11-02 Galin Galchev System and method for monitoring threads in a clustered server architecture
US7853698B2 (en) * 2005-04-29 2010-12-14 Sap Ag Internal persistence of session state information
US8024566B2 (en) * 2005-04-29 2011-09-20 Sap Ag Persistent storage implementations for session data within a multi-tiered enterprise network
US7761435B2 (en) * 2005-04-29 2010-07-20 Sap Ag External persistence of session state information
US9269117B2 (en) * 2005-05-10 2016-02-23 Mckesson Technologies Inc. Enterprise management system
US8719396B2 (en) * 2005-05-20 2014-05-06 Vibrant Media Limited Fraud prevention and detection for online advertising
US9922031B2 (en) * 2005-11-09 2018-03-20 Ca, Inc. System and method for efficient directory performance using non-persistent storage
US8478898B2 (en) * 2005-11-09 2013-07-02 Ca, Inc. System and method for routing directory service operations in a directory service network
US8572201B2 (en) * 2005-11-09 2013-10-29 Ca, Inc. System and method for providing a directory service network
US8707323B2 (en) 2005-12-30 2014-04-22 Sap Ag Load balancing algorithm for servicing client requests
US20080115213A1 (en) * 2006-11-14 2008-05-15 Fmr Corp. Detecting Fraudulent Activity on a Network Using Stored Information
US7856494B2 (en) 2006-11-14 2010-12-21 Fmr Llc Detecting and interdicting fraudulent activity on a network
US8112747B2 (en) * 2006-11-27 2012-02-07 Sap Ag Integrated software support for a distributed business application with seamless backend communications
US8607197B2 (en) * 2007-08-28 2013-12-10 International Business Machines Corporation Displaying HTTP session entry and exit points
US8032858B2 (en) * 2007-08-28 2011-10-04 International Business Machines Corporation Method and system for navigationally displaying HTTP session entry and exit points
US9054882B2 (en) * 2007-10-30 2015-06-09 Cisco Technology, Inc. System and method for associating an end user for billing in a network environment
US8606768B2 (en) * 2007-12-20 2013-12-10 Accenture Global Services Limited System for providing a configurable adaptor for mediating systems
US7962635B2 (en) * 2009-02-24 2011-06-14 Telcordia Technologies, Inc. Systems and methods for single session management in load balanced application server clusters
CN104932946B (en) * 2009-07-28 2022-01-25 瑞典爱立信有限公司 Device and method for handling events in a telecommunications network
US9727534B1 (en) 2012-06-18 2017-08-08 Bromium, Inc. Synchronizing cookie data using a virtualized browser
US9384026B1 (en) * 2012-06-18 2016-07-05 Bromium, Inc. Sharing and injecting cookies into virtual machines for retrieving requested web pages
US10095662B1 (en) 2012-06-18 2018-10-09 Bromium, Inc. Synchronizing resources of a virtualized browser
US9734131B1 (en) 2012-06-18 2017-08-15 Bromium, Inc. Synchronizing history data across a virtualized web browser
CN116383669A (en) * 2023-03-18 2023-07-04 宝钢工程技术集团有限公司 Method and system for generating factory object position number identification through data

Citations (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5274804A (en) * 1991-11-20 1993-12-28 Parcplace Systems Automatic storage-reclamation postmortem finalization process
US5692193A (en) 1994-03-31 1997-11-25 Nec Research Institute, Inc. Software architecture for control of highly parallel computer systems
US5805790A (en) 1995-03-23 1998-09-08 Hitachi, Ltd. Fault recovery method and apparatus
US5835724A (en) 1996-07-03 1998-11-10 Electronic Data Systems Corporation System and method for communication information using the internet that receives and maintains information concerning the client and generates and conveys the session data to the client
US5870742A (en) 1996-03-20 1999-02-09 International Business Machines Corporation Method and apparatus for enabling persistent attributes in an object oriented environment
US5884316A (en) * 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US5887141A (en) 1994-12-02 1999-03-23 Xcellenet, Inc. Systems for work assignment and distribution from a server to remote/mobile nodes by a hierarchy of session work objects into which events can be assigned
US6047295A (en) * 1998-05-05 2000-04-04 International Business Machines Corporation Computer system, program product and method of managing weak references with a concurrent mark sweep collector
US6098093A (en) 1998-03-19 2000-08-01 International Business Machines Corp. Maintaining sessions in a clustered server environment
US6144991A (en) 1998-02-19 2000-11-07 Telcordia Technologies, Inc. System and method for managing interactions between users in a browser-based telecommunications network
US6216152B1 (en) 1997-10-27 2001-04-10 Sun Microsystems, Inc. Method and apparatus for providing plug in media decoders
US20010054004A1 (en) * 2000-06-07 2001-12-20 Powers Arthur C. Method of direct communication between a business and its customers
US6338089B1 (en) 1998-10-06 2002-01-08 Bull Hn Information Systems Inc. Method and system for providing session pools for high performance web browser and server communications
US6339782B1 (en) 1997-11-21 2002-01-15 International Business Machines Corporation Persistence mechanism and method for objects
US20020046304A1 (en) 2000-10-06 2002-04-18 Andreas Fabri Dynamic class loading
US6389460B1 (en) * 1998-05-13 2002-05-14 Compaq Computer Corporation Method and apparatus for efficient storage and retrieval of objects in and from an object storage device
US20020078060A1 (en) 2000-02-14 2002-06-20 Next Computer, Inc. Transparent local and distributed memory management system
US20020078192A1 (en) * 2000-08-01 2002-06-20 Stefan Kopsell Cookie manager for control of cookie transfer in internet client-server computer systems
US20020116505A1 (en) 2001-02-19 2002-08-22 Geoff Higgins Content provider and method for a computer system
US20020143958A1 (en) 2001-03-30 2002-10-03 Montero Gabriel G. Method and apparatus for asynchronous time-based updates of http sessions
US20020152429A1 (en) 2001-04-12 2002-10-17 Bjorn Bergsten Method and apparatus for managing session information
US20020165909A1 (en) 2001-05-01 2002-11-07 International Business Machines Corporation Method for adapting an internet web server to short-term changes in demand
US20020188678A1 (en) 2001-06-05 2002-12-12 Edecker Ada Mae Networked computer system for communicating and operating in a virtual reality environment
US20020198923A1 (en) 2001-06-26 2002-12-26 International Business Machines Corporation Technique for scheduling execution of jobs for or by network-connected devices
US6502148B1 (en) 1999-04-30 2002-12-31 Imagex.Com, Inc. System for scaling an application server system
US20030014521A1 (en) 2001-06-28 2003-01-16 Jeremy Elson Open platform architecture for shared resource access management
US20030014525A1 (en) * 2001-07-12 2003-01-16 International Business Machines Corporation Method and apparatus for policy-based packet classification
US20030018707A1 (en) * 2001-07-20 2003-01-23 Flocken Philip Andrew Server-side filter for corrupt web-browser cookies
US20030018717A1 (en) 2000-03-23 2003-01-23 Michael Haley Extensible information distribution mechanism for session management
US20030033344A1 (en) 2001-08-06 2003-02-13 International Business Machines Corporation Method and apparatus for suspending a software virtual machine
US6523027B1 (en) 1999-07-30 2003-02-18 Accenture Llp Interfacing servers in a Java based e-commerce architecture
US6539445B1 (en) 2000-01-10 2003-03-25 Imagex.Com, Inc. Method for load balancing in an application server system
US20030074580A1 (en) 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
US20030084248A1 (en) 2001-10-31 2003-05-01 Gaither Blaine D. Computer performance improvement by adjusting a count used for preemptive eviction of cache entries
US20030167333A1 (en) * 2002-03-01 2003-09-04 Sun Microsystems, Inc. System and method for state saves in a distributed data system
US20030177382A1 (en) 2002-03-16 2003-09-18 Yoram Ofek Trusted flow and operation control method
US20030212654A1 (en) 2002-01-25 2003-11-13 Harper Jonathan E. Data integration system and method for presenting 360° customer views
US20030229529A1 (en) 2000-02-25 2003-12-11 Yet Mui Method for enterprise workforce planning
EP1387262A1 (en) 2002-05-17 2004-02-04 Abb Research Ltd. Method to generate synchronization contracts for software components and web services
US20040024971A1 (en) 2000-09-21 2004-02-05 Zohar Bogin Method and apparatus for write cache flush and fill mechanisms
US20040049673A1 (en) 2002-09-05 2004-03-11 Docomo Communications Laboratories Usa, Inc. Apparatus and method for a personal cookie repository service for cookie management among multiple devices
US20040068554A1 (en) 2002-05-01 2004-04-08 Bea Systems, Inc. Web service-enabled portlet wizard
US6721777B1 (en) 2000-05-24 2004-04-13 Sun Microsystems, Inc. Modular and portable deployment of a resource adapter in an application server
WO2004038586A2 (en) 2002-10-25 2004-05-06 Sap Aktiengesellschaft Session coupling
US20040098726A1 (en) 2002-11-15 2004-05-20 International Business Machines Corporation JMS integration into an application server
US6751797B1 (en) 1999-10-26 2004-06-15 Bull S.A. System and method for managing the persistence of EJB components in a directory accessed via LDAP
US20040117486A1 (en) * 2002-03-27 2004-06-17 International Business Machines Corporation Secure cache of web session information using web browser cookies
US6763440B1 (en) 2000-06-02 2004-07-13 Sun Microsystems, Inc. Garbage collection using nursery regions for new objects in a virtual heap
US20040153509A1 (en) 1999-06-30 2004-08-05 Alcorn Robert L. Internet-based education support system, method and medium with modular text-editing component for use in a web-based application
US20040172618A1 (en) 2003-02-28 2004-09-02 Bea Systems, Inc. Systems and methods for a common runtime container framework
US20040181537A1 (en) 2003-03-14 2004-09-16 Sybase, Inc. System with Methodology for Executing Relational Operations Over Relational Data and Data Retrieved from SOAP Operations
US20040210500A1 (en) 2002-09-09 2004-10-21 William Sobel Method and apparatus for network-based portfolio management and risk-analysis
US20040221261A1 (en) 2002-05-01 2004-11-04 Mike Blevins Collaborative business plug-in framework
US20040250248A1 (en) 2003-02-24 2004-12-09 Halpern Eric M. System and method for server load balancing and server affinity
US6842770B1 (en) 2000-08-18 2005-01-11 Apple Computer, Inc. Method and system for seamlessly accessing remotely stored files
US6854115B1 (en) 2000-06-02 2005-02-08 Sun Microsystems, Inc. Process persistence in a virtual machine
US6938085B1 (en) 1999-09-24 2005-08-30 Sun Microsystems, Inc. Mechanism for enabling session information to be shared across multiple processes
US6941307B2 (en) 2001-01-24 2005-09-06 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement and a method relating to session management in a portal structure
US6950822B1 (en) 2002-11-06 2005-09-27 Oracle International Corporation Techniques for increasing efficiency while servicing requests for database services
US20050246714A1 (en) 2004-04-28 2005-11-03 International Business Machines Corporation Pooling stateful session enterprise JAVA beans for reuse
US20050256880A1 (en) 2002-10-10 2005-11-17 Whon Nam Koong Method and system for providing content
US20050278270A1 (en) 2004-06-14 2005-12-15 Hewlett-Packard Development Company, L.P. Data services handler
US20050278341A1 (en) 2004-05-28 2005-12-15 Kostadinov Dimitar P Component offline deploy
US20050278278A1 (en) 2004-05-28 2005-12-15 Petev Petio G Class loading jar operation optimizations
US20050278346A1 (en) 2004-06-10 2005-12-15 Sybase, Inc. System Providing Methodology for Replication Subscription Resolution
US20050283585A1 (en) 2004-06-21 2005-12-22 Harlan Sexton Architecture for a scalable and user-extensible heap dump analysis tool
US20050289536A1 (en) 2004-06-23 2005-12-29 International Business Machines Coporation Automated deployment of an application
US20060026286A1 (en) 2004-07-06 2006-02-02 Oracle International Corporation System and method for managing user session meta-data in a reverse proxy
US20060029054A1 (en) 2004-04-29 2006-02-09 International Business Machines Corporation System and method for modeling and dynamically deploying services into a distributed networking architecture
US20060036448A1 (en) 2001-06-13 2006-02-16 Caminus Corporation System architecture and method for energy industry trading and transaction management
US20060036617A1 (en) 2004-08-12 2006-02-16 Oracle International Corporation Suspending a result set and continuing from a suspended result set for transparent session migration
US20060047974A1 (en) 2004-08-30 2006-03-02 Alpern Bowen L Method and apparatus for simplifying the deployment and serviceability of commercial software environments
US20060053087A1 (en) 2004-06-08 2006-03-09 Pavlov Vladimir K System and method for deploying enterprise components using deployment descriptors
US20060053112A1 (en) 2004-09-03 2006-03-09 Sybase, Inc. Database System Providing SQL Extensions for Automated Encryption and Decryption of Column Data
US7013329B1 (en) 2000-08-04 2006-03-14 Oracle International Corporation Techniques for programming event-driven transactions in mobile applications
US20060089992A1 (en) 2004-10-26 2006-04-27 Blaho Bruce E Remote computing systems and methods for supporting multiple sessions
US20060130063A1 (en) 2004-12-14 2006-06-15 Frank Kilian Fast platform independent inter-process communication
US20060143608A1 (en) 2004-12-28 2006-06-29 Jan Dostert Thread monitoring using shared memory
US20060143609A1 (en) 2004-12-28 2006-06-29 Georgi Stanev System and method for managing memory of Java session objects
US20060143389A1 (en) 2004-12-28 2006-06-29 Frank Kilian Main concept for common cache management
US20060143217A1 (en) 2004-12-28 2006-06-29 Georgi Stanev Session management within a multi-tiered enterprise network
US20060143387A1 (en) 2004-12-28 2006-06-29 Petev Petio G Programming models for storage plug-ins
US20060143328A1 (en) 2004-12-28 2006-06-29 Christian Fleischer Failover protection from a failed worker node in a shared memory system
US20060155756A1 (en) 2004-12-28 2006-07-13 Georgi Stanev Session lifecycle management within a multi-tiered enterprise network
US20060155867A1 (en) 2004-12-28 2006-07-13 Frank Kilian Connection manager having a common dispatcher for heterogeneous software suites
US20060206856A1 (en) 2002-12-12 2006-09-14 Timothy Breeden System and method for software application development in a portal environment
US20060236306A1 (en) 2005-04-18 2006-10-19 Debruin David System and method for generating a web service definition and database schema from wireless application definition
US20060248198A1 (en) * 2005-04-29 2006-11-02 Galin Galchev Flexible failover configuration
US20060248200A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Shared memory implementations for session data within a multi-tiered enterprise network
US20060248199A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Shared closure persistence of session state information
US20060248119A1 (en) 2005-04-29 2006-11-02 Georgi Stanev External persistence of session state information
US20060248036A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Internal persistence of session state information
US20060248283A1 (en) 2005-04-29 2006-11-02 Galin Galchev System and method for monitoring threads in a clustered server architecture
US20060248350A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Persistent storage implementations for session data within a multi-tiered enterprise network
US7139792B1 (en) 2000-09-29 2006-11-21 Intel Corporation Mechanism for locking client requests to a particular server
US7165241B2 (en) 2002-11-26 2007-01-16 Sun Microsystems, Inc. Mechanism for testing execution of applets with plug-ins and applications
US7167917B2 (en) 2002-01-03 2007-01-23 International Business Machines Corporation Visual tool for developing service components for use in advanced intelligent networks
US7174363B1 (en) 2001-02-22 2007-02-06 Charles Schwab & Co., Inc. Distributed computing system architecture
US7177823B2 (en) 2001-11-06 2007-02-13 International Business Machines Corporation In-queue jobs information monitoring and filtering
US7185096B2 (en) 2003-05-27 2007-02-27 Sun Microsystems, Inc. System and method for cluster-sensitive sticky load balancing
US7184922B2 (en) 2004-08-27 2007-02-27 National Instruments Corporation Measurement device that appears to a computer system as a file storage device
US7203944B1 (en) 2003-07-09 2007-04-10 Veritas Operating Corporation Migrating virtual machines among computer systems to balance load caused by virtual machines
US7222165B1 (en) * 1998-05-26 2007-05-22 British Telecommunications Plc Service provision support system
US7231435B2 (en) 2001-10-29 2007-06-12 Canon Kabushiki Kaisha Network system, information processing apparatus, information processing method, and control program
US7254634B1 (en) 2002-03-08 2007-08-07 Akamai Technologies, Inc. Managing web tier session state objects in a content delivery network (CDN)
US7266616B1 (en) 2001-08-08 2007-09-04 Pasternak Solutions Llc Method and system for digital rendering over a network
US7277935B2 (en) 2001-07-12 2007-10-02 Allied Telesis Holdings K.K. Management method for network device
US20070245167A1 (en) 2004-01-20 2007-10-18 International Business Machines Corporation Managing failover of j2ee compliant middleware in a high availability system
US7296267B2 (en) 2002-07-12 2007-11-13 Intel Corporation System and method for binding virtual machines to hardware contexts
US7302423B2 (en) 2000-02-25 2007-11-27 Pedestrain Concepts Llc Search-on-the-fly with merge function
US7302609B2 (en) 2003-03-12 2007-11-27 Vladimir Matena Method and apparatus for executing applications on a distributed computer system
US20080086564A1 (en) 2002-01-15 2008-04-10 Janis Rae Putman Communication application server for converged communication services
US7373661B2 (en) 2005-02-14 2008-05-13 Ethome, Inc. Systems and methods for automatically configuring and managing network devices and virtual private networks
US7409709B2 (en) 2005-02-14 2008-08-05 Etsec, Inc. Systems and methods for automatically reconfiguring a network device
US20080201417A1 (en) * 2003-10-30 2008-08-21 International Business Machines Corporation Method and system for providing version control of parameters in a command-based api using java serialization
US7418560B2 (en) 2004-09-23 2008-08-26 Sap Ag Centralized cache storage for runtime systems
US7421495B2 (en) 2003-06-27 2008-09-02 Computer Associates Think, Inc. System and method for monitoring network devices
US20080222270A1 (en) * 2000-12-21 2008-09-11 Bellsouth Intellectual Property Corporation Cookie Management Systems and Methods
US7467162B2 (en) 2005-06-27 2008-12-16 Microsoft Corporation Pre-configured settings for portable devices
US7543051B2 (en) 2003-05-30 2009-06-02 Borland Software Corporation Method of non-intrusive analysis of secure and non-secure web application traffic in real-time
US8112747B2 (en) * 2006-11-27 2012-02-07 Sap Ag Integrated software support for a distributed business application with seamless backend communications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3770063B2 (en) * 2000-08-23 2006-04-26 日本電気株式会社 Time slot allocation system and method and network side apparatus in communication system
US7443902B2 (en) * 2003-10-15 2008-10-28 California Institute Of Technology Laser-based optical switches and logic
US7123435B1 (en) * 2004-06-03 2006-10-17 Maxtor Corporation Method and apparatus for overwriting data in a disk drive

Patent Citations (130)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5274804A (en) * 1991-11-20 1993-12-28 Parcplace Systems Automatic storage-reclamation postmortem finalization process
US5692193A (en) 1994-03-31 1997-11-25 Nec Research Institute, Inc. Software architecture for control of highly parallel computer systems
US5887141A (en) 1994-12-02 1999-03-23 Xcellenet, Inc. Systems for work assignment and distribution from a server to remote/mobile nodes by a hierarchy of session work objects into which events can be assigned
US5805790A (en) 1995-03-23 1998-09-08 Hitachi, Ltd. Fault recovery method and apparatus
US5870742A (en) 1996-03-20 1999-02-09 International Business Machines Corporation Method and apparatus for enabling persistent attributes in an object oriented environment
US5835724A (en) 1996-07-03 1998-11-10 Electronic Data Systems Corporation System and method for communication information using the internet that receives and maintains information concerning the client and generates and conveys the session data to the client
US5884316A (en) * 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US6216152B1 (en) 1997-10-27 2001-04-10 Sun Microsystems, Inc. Method and apparatus for providing plug in media decoders
US6654765B2 (en) 1997-10-27 2003-11-25 Sun Microsystems, Inc. Method and apparatus for providing plug-in media decoders
US6339782B1 (en) 1997-11-21 2002-01-15 International Business Machines Corporation Persistence mechanism and method for objects
US6144991A (en) 1998-02-19 2000-11-07 Telcordia Technologies, Inc. System and method for managing interactions between users in a browser-based telecommunications network
US6098093A (en) 1998-03-19 2000-08-01 International Business Machines Corp. Maintaining sessions in a clustered server environment
US6047295A (en) * 1998-05-05 2000-04-04 International Business Machines Corporation Computer system, program product and method of managing weak references with a concurrent mark sweep collector
US6389460B1 (en) * 1998-05-13 2002-05-14 Compaq Computer Corporation Method and apparatus for efficient storage and retrieval of objects in and from an object storage device
US6675214B2 (en) * 1998-05-13 2004-01-06 Hewlett-Packard Development Company, L.P. Method and apparatus for efficient storage and retrieval of objects in and from an object storage device
US7222165B1 (en) * 1998-05-26 2007-05-22 British Telecommunications Plc Service provision support system
US6338089B1 (en) 1998-10-06 2002-01-08 Bull Hn Information Systems Inc. Method and system for providing session pools for high performance web browser and server communications
US6502148B1 (en) 1999-04-30 2002-12-31 Imagex.Com, Inc. System for scaling an application server system
US20040153509A1 (en) 1999-06-30 2004-08-05 Alcorn Robert L. Internet-based education support system, method and medium with modular text-editing component for use in a web-based application
US6523027B1 (en) 1999-07-30 2003-02-18 Accenture Llp Interfacing servers in a Java based e-commerce architecture
US6938085B1 (en) 1999-09-24 2005-08-30 Sun Microsystems, Inc. Mechanism for enabling session information to be shared across multiple processes
US6751797B1 (en) 1999-10-26 2004-06-15 Bull S.A. System and method for managing the persistence of EJB components in a directory accessed via LDAP
US6539445B1 (en) 2000-01-10 2003-03-25 Imagex.Com, Inc. Method for load balancing in an application server system
US20020078060A1 (en) 2000-02-14 2002-06-20 Next Computer, Inc. Transparent local and distributed memory management system
US7302423B2 (en) 2000-02-25 2007-11-27 Pedestrain Concepts Llc Search-on-the-fly with merge function
US20030229529A1 (en) 2000-02-25 2003-12-11 Yet Mui Method for enterprise workforce planning
US20030018717A1 (en) 2000-03-23 2003-01-23 Michael Haley Extensible information distribution mechanism for session management
US6721777B1 (en) 2000-05-24 2004-04-13 Sun Microsystems, Inc. Modular and portable deployment of a resource adapter in an application server
US6854115B1 (en) 2000-06-02 2005-02-08 Sun Microsystems, Inc. Process persistence in a virtual machine
US6763440B1 (en) 2000-06-02 2004-07-13 Sun Microsystems, Inc. Garbage collection using nursery regions for new objects in a virtual heap
US20010054004A1 (en) * 2000-06-07 2001-12-20 Powers Arthur C. Method of direct communication between a business and its customers
US20020078192A1 (en) * 2000-08-01 2002-06-20 Stefan Kopsell Cookie manager for control of cookie transfer in internet client-server computer systems
US7013329B1 (en) 2000-08-04 2006-03-14 Oracle International Corporation Techniques for programming event-driven transactions in mobile applications
US6842770B1 (en) 2000-08-18 2005-01-11 Apple Computer, Inc. Method and system for seamlessly accessing remotely stored files
US20040024971A1 (en) 2000-09-21 2004-02-05 Zohar Bogin Method and apparatus for write cache flush and fill mechanisms
US7139792B1 (en) 2000-09-29 2006-11-21 Intel Corporation Mechanism for locking client requests to a particular server
US20020046304A1 (en) 2000-10-06 2002-04-18 Andreas Fabri Dynamic class loading
US20080222270A1 (en) * 2000-12-21 2008-09-11 Bellsouth Intellectual Property Corporation Cookie Management Systems and Methods
US6941307B2 (en) 2001-01-24 2005-09-06 Telefonaktiebolaget Lm Ericsson (Publ) Arrangement and a method relating to session management in a portal structure
US20020116505A1 (en) 2001-02-19 2002-08-22 Geoff Higgins Content provider and method for a computer system
US7174363B1 (en) 2001-02-22 2007-02-06 Charles Schwab & Co., Inc. Distributed computing system architecture
US20030074580A1 (en) 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
US20020143958A1 (en) 2001-03-30 2002-10-03 Montero Gabriel G. Method and apparatus for asynchronous time-based updates of http sessions
US20020152429A1 (en) 2001-04-12 2002-10-17 Bjorn Bergsten Method and apparatus for managing session information
US20020165909A1 (en) 2001-05-01 2002-11-07 International Business Machines Corporation Method for adapting an internet web server to short-term changes in demand
US20020188678A1 (en) 2001-06-05 2002-12-12 Edecker Ada Mae Networked computer system for communicating and operating in a virtual reality environment
US20060036448A1 (en) 2001-06-13 2006-02-16 Caminus Corporation System architecture and method for energy industry trading and transaction management
US20020198923A1 (en) 2001-06-26 2002-12-26 International Business Machines Corporation Technique for scheduling execution of jobs for or by network-connected devices
US20030014521A1 (en) 2001-06-28 2003-01-16 Jeremy Elson Open platform architecture for shared resource access management
US20030014525A1 (en) * 2001-07-12 2003-01-16 International Business Machines Corporation Method and apparatus for policy-based packet classification
US7308501B2 (en) * 2001-07-12 2007-12-11 International Business Machines Corporation Method and apparatus for policy-based packet classification using hashing algorithm
US7277935B2 (en) 2001-07-12 2007-10-02 Allied Telesis Holdings K.K. Management method for network device
US20030018707A1 (en) * 2001-07-20 2003-01-23 Flocken Philip Andrew Server-side filter for corrupt web-browser cookies
US20030033344A1 (en) 2001-08-06 2003-02-13 International Business Machines Corporation Method and apparatus for suspending a software virtual machine
US7266616B1 (en) 2001-08-08 2007-09-04 Pasternak Solutions Llc Method and system for digital rendering over a network
US7231435B2 (en) 2001-10-29 2007-06-12 Canon Kabushiki Kaisha Network system, information processing apparatus, information processing method, and control program
US20030084248A1 (en) 2001-10-31 2003-05-01 Gaither Blaine D. Computer performance improvement by adjusting a count used for preemptive eviction of cache entries
US7177823B2 (en) 2001-11-06 2007-02-13 International Business Machines Corporation In-queue jobs information monitoring and filtering
US7167917B2 (en) 2002-01-03 2007-01-23 International Business Machines Corporation Visual tool for developing service components for use in advanced intelligent networks
US20080086564A1 (en) 2002-01-15 2008-04-10 Janis Rae Putman Communication application server for converged communication services
US20030212654A1 (en) 2002-01-25 2003-11-13 Harper Jonathan E. Data integration system and method for presenting 360° customer views
US20030167333A1 (en) * 2002-03-01 2003-09-04 Sun Microsystems, Inc. System and method for state saves in a distributed data system
US7254634B1 (en) 2002-03-08 2007-08-07 Akamai Technologies, Inc. Managing web tier session state objects in a content delivery network (CDN)
US20030177382A1 (en) 2002-03-16 2003-09-18 Yoram Ofek Trusted flow and operation control method
US7197568B2 (en) * 2002-03-27 2007-03-27 International Business Machines Corporation Secure cache of web session information using web browser cookies
US20040117486A1 (en) * 2002-03-27 2004-06-17 International Business Machines Corporation Secure cache of web session information using web browser cookies
US20040221261A1 (en) 2002-05-01 2004-11-04 Mike Blevins Collaborative business plug-in framework
US20040068554A1 (en) 2002-05-01 2004-04-08 Bea Systems, Inc. Web service-enabled portlet wizard
EP1387262A1 (en) 2002-05-17 2004-02-04 Abb Research Ltd. Method to generate synchronization contracts for software components and web services
US7296267B2 (en) 2002-07-12 2007-11-13 Intel Corporation System and method for binding virtual machines to hardware contexts
US20040049673A1 (en) 2002-09-05 2004-03-11 Docomo Communications Laboratories Usa, Inc. Apparatus and method for a personal cookie repository service for cookie management among multiple devices
US20040210500A1 (en) 2002-09-09 2004-10-21 William Sobel Method and apparatus for network-based portfolio management and risk-analysis
US20050256880A1 (en) 2002-10-10 2005-11-17 Whon Nam Koong Method and system for providing content
WO2004038586A2 (en) 2002-10-25 2004-05-06 Sap Aktiengesellschaft Session coupling
US6950822B1 (en) 2002-11-06 2005-09-27 Oracle International Corporation Techniques for increasing efficiency while servicing requests for database services
US20040098726A1 (en) 2002-11-15 2004-05-20 International Business Machines Corporation JMS integration into an application server
US7165241B2 (en) 2002-11-26 2007-01-16 Sun Microsystems, Inc. Mechanism for testing execution of applets with plug-ins and applications
US20060206856A1 (en) 2002-12-12 2006-09-14 Timothy Breeden System and method for software application development in a portal environment
US7406692B2 (en) 2003-02-24 2008-07-29 Bea Systems, Inc. System and method for server load balancing and server affinity
US20040250248A1 (en) 2003-02-24 2004-12-09 Halpern Eric M. System and method for server load balancing and server affinity
US20040172618A1 (en) 2003-02-28 2004-09-02 Bea Systems, Inc. Systems and methods for a common runtime container framework
US7302609B2 (en) 2003-03-12 2007-11-27 Vladimir Matena Method and apparatus for executing applications on a distributed computer system
US20040181537A1 (en) 2003-03-14 2004-09-16 Sybase, Inc. System with Methodology for Executing Relational Operations Over Relational Data and Data Retrieved from SOAP Operations
US7185096B2 (en) 2003-05-27 2007-02-27 Sun Microsystems, Inc. System and method for cluster-sensitive sticky load balancing
US7543051B2 (en) 2003-05-30 2009-06-02 Borland Software Corporation Method of non-intrusive analysis of secure and non-secure web application traffic in real-time
US7421495B2 (en) 2003-06-27 2008-09-02 Computer Associates Think, Inc. System and method for monitoring network devices
US7203944B1 (en) 2003-07-09 2007-04-10 Veritas Operating Corporation Migrating virtual machines among computer systems to balance load caused by virtual machines
US20080201417A1 (en) * 2003-10-30 2008-08-21 International Business Machines Corporation Method and system for providing version control of parameters in a command-based api using java serialization
US20070245167A1 (en) 2004-01-20 2007-10-18 International Business Machines Corporation Managing failover of j2ee compliant middleware in a high availability system
US20050246714A1 (en) 2004-04-28 2005-11-03 International Business Machines Corporation Pooling stateful session enterprise JAVA beans for reuse
US20060029054A1 (en) 2004-04-29 2006-02-09 International Business Machines Corporation System and method for modeling and dynamically deploying services into a distributed networking architecture
US20050278341A1 (en) 2004-05-28 2005-12-15 Kostadinov Dimitar P Component offline deploy
US20050278278A1 (en) 2004-05-28 2005-12-15 Petev Petio G Class loading jar operation optimizations
US20060053087A1 (en) 2004-06-08 2006-03-09 Pavlov Vladimir K System and method for deploying enterprise components using deployment descriptors
US20050278346A1 (en) 2004-06-10 2005-12-15 Sybase, Inc. System Providing Methodology for Replication Subscription Resolution
US20050278270A1 (en) 2004-06-14 2005-12-15 Hewlett-Packard Development Company, L.P. Data services handler
US20050283585A1 (en) 2004-06-21 2005-12-22 Harlan Sexton Architecture for a scalable and user-extensible heap dump analysis tool
US20050289536A1 (en) 2004-06-23 2005-12-29 International Business Machines Coporation Automated deployment of an application
US20060026286A1 (en) 2004-07-06 2006-02-02 Oracle International Corporation System and method for managing user session meta-data in a reverse proxy
US20060036617A1 (en) 2004-08-12 2006-02-16 Oracle International Corporation Suspending a result set and continuing from a suspended result set for transparent session migration
US7184922B2 (en) 2004-08-27 2007-02-27 National Instruments Corporation Measurement device that appears to a computer system as a file storage device
US20060047974A1 (en) 2004-08-30 2006-03-02 Alpern Bowen L Method and apparatus for simplifying the deployment and serviceability of commercial software environments
US20060053112A1 (en) 2004-09-03 2006-03-09 Sybase, Inc. Database System Providing SQL Extensions for Automated Encryption and Decryption of Column Data
US7418560B2 (en) 2004-09-23 2008-08-26 Sap Ag Centralized cache storage for runtime systems
US20060089992A1 (en) 2004-10-26 2006-04-27 Blaho Bruce E Remote computing systems and methods for supporting multiple sessions
US20060130063A1 (en) 2004-12-14 2006-06-15 Frank Kilian Fast platform independent inter-process communication
US20060155756A1 (en) 2004-12-28 2006-07-13 Georgi Stanev Session lifecycle management within a multi-tiered enterprise network
US20060143217A1 (en) 2004-12-28 2006-06-29 Georgi Stanev Session management within a multi-tiered enterprise network
US8015561B2 (en) 2004-12-28 2011-09-06 Sap Ag System and method for managing memory of Java session objects
US20060143608A1 (en) 2004-12-28 2006-06-29 Jan Dostert Thread monitoring using shared memory
US20060143609A1 (en) 2004-12-28 2006-06-29 Georgi Stanev System and method for managing memory of Java session objects
US20060143389A1 (en) 2004-12-28 2006-06-29 Frank Kilian Main concept for common cache management
US20060155867A1 (en) 2004-12-28 2006-07-13 Frank Kilian Connection manager having a common dispatcher for heterogeneous software suites
US20060143387A1 (en) 2004-12-28 2006-06-29 Petev Petio G Programming models for storage plug-ins
US20060143328A1 (en) 2004-12-28 2006-06-29 Christian Fleischer Failover protection from a failed worker node in a shared memory system
US7409709B2 (en) 2005-02-14 2008-08-05 Etsec, Inc. Systems and methods for automatically reconfiguring a network device
US7373661B2 (en) 2005-02-14 2008-05-13 Ethome, Inc. Systems and methods for automatically configuring and managing network devices and virtual private networks
US20060236306A1 (en) 2005-04-18 2006-10-19 Debruin David System and method for generating a web service definition and database schema from wireless application definition
US20060248198A1 (en) * 2005-04-29 2006-11-02 Galin Galchev Flexible failover configuration
US20060248119A1 (en) 2005-04-29 2006-11-02 Georgi Stanev External persistence of session state information
US20060248283A1 (en) 2005-04-29 2006-11-02 Galin Galchev System and method for monitoring threads in a clustered server architecture
US20060248036A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Internal persistence of session state information
US20060248200A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Shared memory implementations for session data within a multi-tiered enterprise network
US20060248350A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Persistent storage implementations for session data within a multi-tiered enterprise network
US7761435B2 (en) 2005-04-29 2010-07-20 Sap Ag External persistence of session state information
US7853698B2 (en) 2005-04-29 2010-12-14 Sap Ag Internal persistence of session state information
US20060248199A1 (en) 2005-04-29 2006-11-02 Georgi Stanev Shared closure persistence of session state information
US8024566B2 (en) 2005-04-29 2011-09-20 Sap Ag Persistent storage implementations for session data within a multi-tiered enterprise network
US7467162B2 (en) 2005-06-27 2008-12-16 Microsoft Corporation Pre-configured settings for portable devices
US8112747B2 (en) * 2006-11-27 2012-02-07 Sap Ag Integrated software support for a distributed business application with seamless backend communications

Non-Patent Citations (97)

* Cited by examiner, † Cited by third party
Title
"SAP Transactions and the VM Container & Resource Management in the VM Container, printed", (Sep. 12, 2009).
"U.S. Appl. No. 11/025,200 , Final Office Action mailed Nov. 16, 2009", 10 Pgs.
"U.S. Appl. No. 11/025,200, Advisory Action mailed Feb. 3, 2010", 3 pgs.
"U.S. Appl. No. 11/025,200, Decision on Pre-Appeal Brief Request mailed Apr. 25, 2011", 2 pgs.
"U.S. Appl. No. 11/025,200, Examiner Interview Summary mailed Jan. 31, 2012", 3 pgs.
"U.S. Appl. No. 11/025,200, Examiner Interview Summary mailed Jun. 23, 2011", 2 pgs.
"U.S. Appl. No. 11/025,200, Examiner Interview Summary mailed Mar. 20, 2009", 3 pgs.
"U.S. Appl. No. 11/025,200, Final Office Action mailed Dec. 16, 2010", 11 pgs.
"U.S. Appl. No. 11/025,200, Non Final Office Action mailed Jul. 12, 2011", 19 pgs.
"U.S. Appl. No. 11/025,200, Non Final Office Action mailed Mar. 24, 2009", 12 pgs.
"U.S. Appl. No. 11/025,200, Non Final Office Action mailed Nov. 4, 2011", 20 pgs.
"U.S. Appl. No. 11/025,200, Non-Final Office Action mailed Aug. 6, 2010", 11 pgs.
"U.S. Appl. No. 11/025,200, Non-Final Office Action mailed Mar. 3, 2010", 11 pgs.
"U.S. Appl. No. 11/025,200, Notice of Allowance mailed Feb. 21, 2012", 21 pgs.
"U.S. Appl. No. 11/025,200, Pre-Appeal Brief Request filed Mar. 8, 2011", 5 pgs.
"U.S. Appl. No. 11/025,200, Preliminary Amendment filed Mar. 24, 2005", 4 pgs.
"U.S. Appl. No. 11/025,200, Response filed Feb. 2, 2012 to Non Final Office Action mailed Nov. 4, 2011", 12 pgs.
"U.S. Appl. No. 11/025,200, Response filed Feb. 9, 2010 to Advisory Action mailed Feb. 3, 2010", 15 pgs.
"U.S. Appl. No. 11/025,200, Response filed Jan. 12, 2010 to Final Office Action mailed Nov. 16, 2009", 5 pgs.
"U.S. Appl. No. 11/025,200, Response filed May 26, 2010 to Non Final Office Action mailed Mar. 3, 2010", 17 pgs.
"U.S. Appl. No. 11/025,200, Response filed Nov. 1, 2010 to Non Final Office Action mailed Aug. 6, 2010", 15 pgs.
"U.S. Appl. No. 11/025,200, Response filed Oct. 7, 2011 to Non Final Office Action mailed Jul. 12, 2011", 17 pgs.
"U.S. Appl. No. 11/025,316 Non-Final Office Action mailed Sep. 3, 2010", 19 pgs.
"U.S. Appl. No. 11/025,316, Advisory Action mailed Apr. 21, 2010", 2 pgs.
"U.S. Appl. No. 11/025,316, Examiner Interview Summary mailed Aug. 12, 2010", 2 pgs.
"U.S. Appl. No. 11/025,316, Examiner Interview Summary mailed May 3, 2011", 1 pg.
"U.S. Appl. No. 11/025,316, Final Office Action mailed Feb. 17, 2011", 19 pgs.
"U.S. Appl. No. 11/025,316, Final Office Action mailed Feb. 23, 2010", 10 pgs.
"U.S. Appl. No. 11/025,316, Non-Final Office Action mailed Jul. 21, 2009", 9 pgs.
"U.S. Appl. No. 11/025,316, Notice of Allowance mailed May 3, 2011", 11 pgs.
"U.S. Appl. No. 11/025,316, Response filed Apr. 12, 2011 to Final Office Action mailed Feb. 17, 2011", 16 pgs.
"U.S. Appl. No. 11/025,316, Response filed Apr. 6, 2010 to Final Office Action mailed Feb. 23, 2010", 9 pgs.
"U.S. Appl. No. 11/025,316, Response filed Dec. 1, 2010 to Non Final Office Action mailed Sep. 3, 2010", 18 pgs.
"U.S. Appl. No. 11/025,316, Response filed Oct. 21, 2009 to Non Final Office Action mailed Jul. 21, 2009", 10 pgs.
"U.S. Appl. No. 11/117,851 Restriction Requirement mailed Sep. 1, 2010", 6 pgs.
"U.S. Appl. No. 11/117,851, Examiner Interview Summary mailed Sep. 2, 2011", 3 pgs.
"U.S. Appl. No. 11/117,851, Final Office Action mailed Dec. 6, 2010", 17 pgs.
"U.S. Appl. No. 11/117,851, Final Office Action mailed Nov. 30, 2011", 27 pgs.
"U.S. Appl. No. 11/117,851, Non Final Office Action mailed May 25, 2011", 24 pgs.
"U.S. Appl. No. 11/117,851, Non-Final Office Action mailed Mar. 17, 2010", 17 pgs.
"U.S. Appl. No. 11/117,851, Response filed Aug. 25, 2011 to Non Final Office Action mailed May 25, 2011", 15 pgs.
"U.S. Appl. No. 11/117,851, Response filed Feb. 17, 2012 to Final Office Action mailed Nov. 30, 2011", 17 pgs.
"U.S. Appl. No. 11/117,851, Response filed Jun. 16, 2010 to Non Final Office Action mailed Mar. 17, 2010", 17 pgs.
"U.S. Appl. No. 11/117,851, Response filed Mar. 3, 2011 to Final Office Action mailed Dec. 6, 2010", 15 pgs.
"U.S. Appl. No. 11/117,851, Response filed Sep. 28, 2010 to Restriction Requirement mailed Sep. 1, 2010", 8 pgs.
"U.S. Appl. No. 11/117,993 Notice of Allowance mailed Sep. 20, 2010", 7 pgs.
"U.S. Appl. No. 11/117,993, Final Office Action mailed Jun. 23, 2010", 18 pgs.
"U.S. Appl. No. 11/117,993, Non Final Office Action mailed Sep. 21, 2009", 11 pgs.
"U.S. Appl. No. 11/117,993, Response filed Aug. 23, 2010 to Final Office Action mailed Jun. 23, 2010", 9 pgs.
"U.S. Appl. No. 11/118,018, Appeal Brief filed Mar. 11, 2011", 38 pgs.
"U.S. Appl. No. 11/118,018, Final Office Action mailed Apr. 9, 2010", 29 pgs.
"U.S. Appl. No. 11/118,018, Final Office Action mailed Dec. 21, 2010", 32 pgs.
"U.S. Appl. No. 11/118,018, Non Final Office Action mailed Oct. 20, 2009", 26 pgs.
"U.S. Appl. No. 11/118,018, Non-Final Office Action mailed Jul. 9, 2010", 27 pgs.
"U.S. Appl. No. 11/118,018, Non-Final Office Action mailed Mar. 20, 2009", 13 pgs.
"U.S. Appl. No. 11/118,018, Notice of Allowance mailed Aug. 8, 2011", 11 pgs.
"U.S. Appl. No. 11/118,018, Notice of Allowance mailed May 20, 2011", 15 pgs.
"U.S. Appl. No. 11/118,018, Response filed Jan. 19, 2010 to Non Final Office Action mailed Oct. 19, 2009", 11 pgs.
"U.S. Appl. No. 11/118,018, Response filed Jun. 16, 2010 to Final Office Action mailed Apr. 9, 2010", 11 pgs.
"U.S. Appl. No. 11/118,018, Response filed Jun. 19, 2009 to Non Final Office Action mailed Mar. 20, 2009", 14 pgs.
"U.S. Appl. No. 11/118,018, Response filed Oct. 4, 2010 to Non Final Office Action mailed Jul. 9, 2010", 13 pgs.
"U.S. Appl. No. 11/118,020, Response filed May 26, 2009 to Non Final Office Action mailed Feb. 24, 2009", 12 pgs.
"U.S. Appl. No. 11/118,890, Advisory Action mailed Sep. 14, 2009", 3 pgs.
"U.S. Appl. No. 11/118,890, Appeal Brief filed Jun. 21, 2010", 21 pgs.
"U.S. Appl. No. 11/118,890, Decision on Pre-Appeal Brief Request mailed May 21, 2010", 2 pgs.
"U.S. Appl. No. 11/118,890, Examiner Interview Summary mailed Mar. 2, 2010", 3 pgs.
"U.S. Appl. No. 11/118,890, Examiner's Answer to Appeal Brief mailed Sep. 3, 2010", 12 pgs.
"U.S. Appl. No. 11/118,890, Final Office Action mailed May 6, 2009", 10 pgs.
"U.S. Appl. No. 11/118,890, Non Final Office Action mailed Sep. 18, 2008", 8 pgs.
"U.S. Appl. No. 11/118,890, Non-Final Office Action mailed Dec. 24, 2009", 10 Pgs.
"U.S. Appl. No. 11/118,890, Pre-Appeal Brief Request mailed Mar. 24, 2010", 5 pgs.
"U.S. Appl. No. 11/118,890, Reply Brief filed Oct. 28, 2010", 4 pgs.
"U.S. Appl. No. 11/118,890, Response filed Jan. 20, 2009 to Non Final Office Action mailed Sep. 18, 2008", 18 pgs.
"U.S. Appl. No. 11/118,890, Response filed Sep. 2, 2009 to Final Office Action mailed May 6, 2009", 11 pgs.
"U.S. Appl. No. 11/118,976, Advisory Action mailed Mar. 30, 2009", 3 pgs.
"U.S. Appl. No. 11/118,976, Examiner Interview Summary mailed Mar. 2, 2010", 3 pgs.
"U.S. Appl. No. 11/118,976, Final Office Action mailed Feb. 21, 2008", 15 pgs.
"U.S. Appl. No. 11/118,976, Final Office Action mailed Feb. 3, 2009", 17 pgs.
"U.S. Appl. No. 11/118,976, Non Final Office Action mailed Aug. 21, 2008", 17 pgs.
"U.S. Appl. No. 11/118,976, Non Final Office Action mailed Aug. 31, 2007", 14 pgs.
"U.S. Appl. No. 11/118,976, Non-Final Office Action mailed Dec. 8, 2009.", 24 pgs.
"U.S. Appl. No. 11/118,976, Non-Final Office Action mailed Jun. 11, 2009", 22 pgs.
"U.S. Appl. No. 11/118,976, Notice of Allowance mailed May 17, 2010", 18 pgs.
"U.S. Appl. No. 11/118,976, Response filed Mar. 19, 2009 to Final Office Action mailed Feb. 3, 2009", 11 pgs.
"U.S. Appl. No. 11/118,976, Response filed Mar. 8, 2010 to Non Final Office Action mailed Dec. 8, 2009", 20 pgs.
"U.S. Appl. No. 11/118,976, Response filed May 23, 2008 to Final Office Action mailed Feb. 21, 208", 11 pgs.
"U.S. Appl. No. 11/118,976, Response filed Nov. 21, 2008 to Non Final Office Action mailed Aug. 21, 2008", 13 pgs.
"U.S. Appl. No. 11/118,976, Response filed Nov. 30, 2007 to Non Final Office Action mailed Aug. 31, 2007", 13 pgs.
"U.S. Appl. No. 11/118,976, Response filed Sep. 9, 2009 to Non Final Office Action mailed Jun. 11, 2009", 18 pgs.
"U.S. Appl. No. 11/406,738, Response filed Dec. 16, 2009 to Non Final Office Action mailed Sep. 21, 2009", 15 pgs.
Jipping, Michael J, et al., "Using Java to teach networking concepts with a programmable network sniffer", SIGCSE Bull. 35, 1, 001= http://doi.acm.org/10.1145/792548.611948, (Jan. 2003), 120-124.
osdir; RE: Barracude: Reference objects in Session/ServletContext: msg#00056; Nov. 2002. *
Parnas, Dagfinn, "SAP Virtual Machine Container", [Online]. Retrieved from the Internet: , (Oct. 23, 2004), 4 pgs.
Parnas, Dagfinn, "SAP Virtual Machine Container", [Online]. Retrieved from the Internet: <URL: https://weblogs.sdn.sap.com/pub/wig/940>, (Oct. 23, 2004), 4 pgs.
Pasin, Macia, et al., "High-Available Enterprise JavaBeans Using Group Communication System Support", XP002285985, 1-6.
Smits, Thomas, "Unbreakable Java-The Java Server that Never Goes Down", Article SAP TechED, San Diego and Munich, (Nov. 2004), 1-5.
Vrtual Machine Container: Unbreakable Java, (2003).

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8799359B2 (en) 2004-12-28 2014-08-05 Sap Ag Session management within a multi-tiered enterprise network
US9432240B2 (en) 2005-04-29 2016-08-30 Sap Se Flexible failover configuration
US8762547B2 (en) 2005-04-29 2014-06-24 Sap Ag Shared memory implementations for session data within a multi-tiered enterprise network
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US20120284725A1 (en) * 2009-07-28 2012-11-08 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and Method for Processing Events in a Telecommunications Network
US9459941B2 (en) * 2009-07-28 2016-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Apparatus and method for synchronizing the processing of events associated with application sessions in a telecommunications network
US20130332618A1 (en) * 2012-06-08 2013-12-12 International Business Machines Corporation Enabling different client contexts to share session information
US9578111B2 (en) * 2012-06-08 2017-02-21 International Business Machines Corporation Enabling different client contexts to share session information
US20150134723A1 (en) * 2013-11-11 2015-05-14 Microsoft Corporation Geo-distributed disaster recovery for interactive cloud applications
US10594784B2 (en) * 2013-11-11 2020-03-17 Microsoft Technology Licensing, Llc Geo-distributed disaster recovery for interactive cloud applications
US9922088B2 (en) 2013-12-31 2018-03-20 Sybase, Inc. Cardinality estimation using spanning trees
US11153319B2 (en) * 2015-10-21 2021-10-19 Okta, Inc. Flexible implementation of user lifecycle events for applications of an enterprise
US11086776B2 (en) * 2018-08-29 2021-08-10 International Business Machines Corporation Maintaining correctness of pointers from a managed heap to off-heap memory

Also Published As

Publication number Publication date
US20060155756A1 (en) 2006-07-13

Similar Documents

Publication Publication Date Title
US8281014B2 (en) Session lifecycle management within a multi-tiered enterprise network
US8799359B2 (en) Session management within a multi-tiered enterprise network
US8762547B2 (en) Shared memory implementations for session data within a multi-tiered enterprise network
US7853698B2 (en) Internal persistence of session state information
US8024566B2 (en) Persistent storage implementations for session data within a multi-tiered enterprise network
US7761435B2 (en) External persistence of session state information
US9432240B2 (en) Flexible failover configuration
US7680879B2 (en) Method and apparatus for maintaining data integrity across distributed computer systems
US20060248199A1 (en) Shared closure persistence of session state information
US7003587B1 (en) Method and apparatus for maintaining data integrity across distributed computer systems
US7831634B2 (en) Initializing a cache region using a generated cache region configuration structure
US7526479B2 (en) Configuration manager in enterprise computing system
US7739290B2 (en) System and method for object persistence
US20060248131A1 (en) Cache isolation model
US20060248285A1 (en) Cache coherence protocol
US20060271395A1 (en) Distributed object identity in a virtual machine cluster
US20060248284A1 (en) Cache coherence implementation using shared locks and message server
US20040128328A1 (en) Method and apparatus for relaxed transactional isolation in a client-server caching architecture
AU779943B2 (en) Method and apparatus for maintaining data integrity across distributed computer systems
US7707155B2 (en) System and method for efficiently filtering and restoring tables within a multi-tiered enterprise network
EP1203296B1 (en) Method and apparatus for maintaining data integrity across distributed computer systems
Kirby et al. Ibm websphere extreme scale v7: Solutions architecture
Leff et al. Enterprise JavaBeans caching in clustered environments
Terracotta, Inc. Theory and Foundation Forming a Common Understanding
AU2007202676A1 (en) Method and apparatus for maintaining data integrity across distributed computer systems

Legal Events

Date Code Title Description
AS Assignment

Owner name: SAP AKTIENGESELLSCHAFT, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STANEV, GEORGI;GALCHEV, GALIN;REEL/FRAME:016146/0616

Effective date: 20041211

FEPP Fee payment procedure

Free format text: PAYER NUMBER DE-ASSIGNED (ORIGINAL EVENT CODE: RMPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: SAP SE, GERMANY

Free format text: CHANGE OF NAME;ASSIGNOR:SAP AG;REEL/FRAME:033625/0334

Effective date: 20140707

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8