Abstract: In accordance with an embodiment, described herein is a system and method for supporting clustering in a multitenant application server environment. The system includes a domain with a plurality of server clusters, and a plurality of partitions, wherein each cluster is homogenously configured and targeted by one or more partitions. An application programming interface (API) can be used to initiate a resource group across-cluster migration within a partition. The API can invoke a replication manager, which queries a target cluster for a runtime topology for use in determining where to store primary session; migrates the primary session to a determined server instance in the target cluster. Additional clustering features, such as cluster messaging service, leasing service, singleton service management, session replication, clustered JNDI, and use of domain front-end load balancing, can be supported.

Abstract: In accordance with an embodiment, described herein is a system and method for handling lazy deserialization exceptions in an application server environment. When a stateful, e.g., EJB client request arrives to the EJB container, if the container detects that it cannot deserialize the state on this server and a patching (Patching, Zero Downtime Patching, ZDT) application upgrade rollout is in progress, the container can ask the replication manager to replicate the bean state to a new secondary that is in the opposite ZDT failover server group of this server, if it can find one. A remote reference of the replica on the new secondary will be set to a special type exception, which carries the replica's remote reference to the client side, in order to fulfill the client request.

Abstract: In accordance with an embodiment, systems and methods for session handling in a multitenant application server environment are provided. The ability to replicate a session is important but equally so is the ability to ensure the session is successfully deserialized on some server in order to serve the request. After a server has been shut down, the front end can fail over the request to one of the remaining server members in a cluster. Once the server receives the request it can attempt to grab the session from a server that holds a copy of that session. When a patched or unpatched server attempts to load the session that originated from a server of the opposite state, it can fail to deserialize the session, and inform the traffic director of severs in the cluster that are capable of deserializing the session.

Abstract: In accordance with an embodiment, described herein is a system and method for handling lazy deserialization exceptions in an application server environment. When a stateful, e.g., EJB client request arrives to the EJB container, if the container detects that it cannot deserialize the state on this server and a patching (Patching, Zero Downtime Patching, ZDT) application upgrade rollout is in progress, the container can ask the replication manager to replicate the bean state to a new secondary that is in the opposite ZDT failover server group of this server, if it can find one. A remote reference of the replica on the new secondary will be set to a special type exception, which carries the replica's remote reference to the client side, in order to fulfill the client request.

Abstract: A system and method can support in-memory session replication in a server cluster using a lazy deserialization approach. The server cluster can include a primary application server and a secondary application server. The primary application server operates to receive a request associated with a session from a client and maintains session information associated with the session. Based on the session information, the primary application server can responds to the client. The secondary application server operates to receive and maintain serialized session information from the primary application server. The secondary application server operates to update the serialized session information based on one or more session updates received from the primary application server. When the primary application server fails, the secondary application server can generate deserialized session information based on the updated serialized session information and responds to the client.

Abstract: In accordance with an embodiment, systems and methods for session handling in a multitenant application server environment are provided. The ability to replicate a session is important but equally so is the ability to ensure the session is successfully deserialized on some server in order to serve the request. After a server has been shut down, the front end can fail over the request to one of the remaining server members in a cluster. Once the server receives the request it can attempt to grab the session from a server that holds a copy of that session. When a patched or unpatched server attempts to load the session that originated from a server of the opposite state, it can fail to deserialize the session, and inform the traffic director of severs in the cluster that are capable of deserializing the session.

Abstract: In accordance with an embodiment, described herein is a system and method for supporting clustering in a multitenant application server environment. The system includes a domain with a plurality of server clusters, and a plurality of partitions, wherein each cluster is homogenously configured and targeted by one or more partitions. An application programming interface (API) can be used to initiate a resource group across-cluster migration within a partition. The API can invoke a replication manager, which queries a target cluster for a runtime topology for use in determining where to store primary session; migrates the primary session to a determined server instance in the target cluster. Additional clustering features, such as cluster messaging service, leasing service, singleton service management, session replication, clustered JNDI, and use of domain front-end load balancing, can be supported.

Abstract: A system and method for providing a middleware machine or similar platform. In accordance with an embodiment the system (referred to herein in some implementations as “Exalogic”) comprises a combination of high performance hardware, together with an application server or middleware environment, to provide a complete Java EE application server complex which includes a massively parallel in-memory grid, can be provisioned quickly, and can scale on demand. In accordance with an embodiment, the system can be deployed as a full, half, or quarter rack, or other configuration, that provides an application server grid, storage area network, and InfiniBand network, which support the execution of an application server, middleware or other functionality such as, for example, WebLogic Server, JRockit or Hotspot JVM, Oracle Linux or Solaris, and Oracle VM. Additional features of the system can include, e.g. Zero Buffer Copies, Scatter/Gather I/O, T3 Connections, and Lazy Deserialization.

Abstract: A system and method for providing a middleware machine or similar platform. In accordance with an embodiment the system (referred to herein in some implementations as “Exalogic”) comprises a combination of high performance hardware, together with an application server or middleware environment, to provide a complete Java EE application server complex which includes a massively parallel in-memory grid, can be provisioned quickly, and can scale on demand. In accordance with an embodiment, the system can be deployed as a full, half, or quarter rack, or other configuration, that provides an application server grid, storage area network, and InfiniBand network, which support the execution of an application server, middleware or other functionality such as, for example, WebLogic Server, JRockit or Hotspot JVM, Oracle Linux or Solaris, and Oracle VM. Additional features of the system can include, e.g. Zero Buffer Copies, Scatter/Gather I/O, T3 Connections, and Lazy Deserialization.

Abstract: A system and method can support in-memory session replication in a server cluster using a lazy deserialization approach. The server cluster can include a primary application server and a secondary application server. The primary application server operates to receive a request associated with a session from a client and maintains session information associated with the session. Based on the session information, the primary application server can responds to the client. The secondary application server operates to receive and maintain serialized session information from the primary application server. The secondary application server operates to update the serialized session information based on one or more session updates received from the primary application server. When the primary application server fails, the secondary application server can generate deserialized session information based on the updated serialized session information and responds to the client.