Abstract: A mechanism is provided for replicating non-supported data types using an existing replication format supported by an existing replication system. Responsive to detecting an application writing data to a local storage that is to be replicated to the secondary site, the input/output (I/O) operation being performed by the application is intercepted. Data of the I/O operation in a non-supported format is converted to a format supported by the existing replication system. A replication log record is generated for the data in the format supported by the existing replication system. The data described by the replication log record for the data is then stored in a storage device at the secondary site.

Abstract: A mechanism is provided for replicating non-supported data types using an existing replication format supported by an existing replication system. Responsive to detecting an application writing data to a local storage that is to be replicated to the secondary site, the input/output (I/O) operation being performed by the application is intercepted. Data of the I/O operation in a non-supported format is converted to a format supported by the existing replication system. A replication log record is generated for the data in the format supported by the existing replication system. The data described by the replication log record for the data is then stored in a storage device at the secondary site.

Abstract: We propose a rule-based system, whereby API requests issued by an application program are screened by policy rules before being acted on by an API, where the policy rules are sensitive to the runtime environment. A policy manager is arranged to screen API requests transmitted by the application program against a set of rules to decide whether a particular API request should be allowed to proceed to the API unchanged or be trapped. Trapping an API request causes an API response to be generated according to the rule that trapped the API request, and then transmission of the generated API response to the application program. This allows dynamic modification of the application program's behavior by the customer in order to respond to changes in the server runtime environment without having to modify the application program by configuring one or more policy rules to influence API request handling.

Abstract: A mechanism is provided for replicating non-supported data types using an existing replication format supported by an existing replication system. Responsive to detecting an application writing data to a local storage that is to be replicated to the secondary site, the input/output (I/O) operation being performed by the application is intercepted. Data of the I/O operation in a non-supported format is converted to a format supported by the existing replication system. A replication log record is generated for the data in the format supported by the existing replication system. The data described by the replication log record for the data is then stored in a storage device at the secondary site.

Abstract: A mechanism is provided for replicating non-supported data types using an existing replication format supported by an existing replication system. Responsive to detecting an application writing data to a local storage that is to be replicated to the secondary site, the input/output (I/O) operation being performed by the application is intercepted. Data of the I/O operation in a non-supported format is converted to a format supported by the existing replication system. A replication log record is generated for the data in the format supported by the existing replication system. The data described by the replication log record for the data is then stored in a storage device at the secondary site.

Abstract: A transaction processing system is operated. A first resource is locked as a shared resource by a first task executing on a computing device. The first task attempts to lock a second resource as an exclusive resource. The occurrence of a deadlock is ascertained. A second task that wishes to use the locked first resource is identified. A current position of the first task with respect to the first resource is stored. The lock on the first resource is removed. The second task is prompted to use the first resource. The first task locks the first resource as the shared resource. The first task is repositioned with respect to first resource according to the stored position. The first task locks the second resource as the exclusive resource. The first task is performed.

Abstract: A computer implemented method handles service requests for HTTP-based services via IP ports that are located on HTTP servers. These HTTP servers are logically coupled to a port sharing mechanism that handles service requests from clients, and each of the multiple HTTP servers provides the same HTTP-based service. A request for the HTTP-based service is sent to an IP port in a first HTTP server. However, this IP port has a current number of active IP connections that exceeds a soft cap. Nonetheless, this IP port is directed to accept and execute the request, and then to terminate its connection with the client. Any subsequent request for this same HTTP-based service is directed to another of the multiple HTTP servers.

Abstract: A computer implemented method, system and/or computer program product handles service requests for HTTP-based services via IP ports that are located on HTTP servers. These HTTP servers are logically coupled to a port sharing mechanism that handles service requests from clients, and each of the multiple HTTP servers provides the same HTTP-based service. A request for the HTTP-based service is sent to an IP port in a first HTTP server. However, this IP port has a current number of active IP connections that exceeds a soft cap. Nonetheless, this IP port is directed to accept and execute the request, and then to terminate its connection with the client. Any subsequent request for this same HTTP-based service is directed to another of the multiple HTTP servers.

Abstract: A computer implemented method handles service requests for HTTP-based services via IP ports that are located on HTTP servers. These HTTP servers are logically coupled to a port sharing mechanism that handles service requests from clients, and each of the multiple HTTP servers provides the same HTTP-based service. A request for the HTTP-based service is sent to an IP port in a first HTTP server. However, this IP port has a current number of active IP connections that exceeds a soft cap. Nonetheless, this IP port is directed to accept and execute the request, and then to terminate its connection with the client. Any subsequent request for this same HTTP-based service is directed to another of the multiple HTTP servers.

Abstract: A transaction processing system is operated. A first resource is locked as a shared resource by a first task executing on a computing device. The first task attempts to lock a second resource as an exclusive resource. The occurrence of a deadlock is ascertained. A second task that wishes to use the locked first resource is identified. A current position of the first task with respect to the first resource is stored. The lock on the first resource is removed. The second task is prompted to use the first resource. The first task locks the first resource as the shared resource. The first task is repositioned with respect to first resource according to the stored position. The first task locks the second resource as the exclusive resource. The first task is performed.