Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A method, system and computer program product for sharing resources among remote repositories. In a shared file system, a resource identifier and metadata are created for a resource, where the resource identifier is stored in a lock file in a shared volume accessible by the remote repositories. The lock file is then released in response to distributing the associated resource to the remote repositories. Alternatively, in a peer-to-peer system, a request is received to create, read, update or delete a resource stored in a content repository. A resource name, a resource version and/or a resource fingerprint are received in connection with the request to create, read, update or delete the resource in the content repository. A determination is then made as to whether the received resource name, resource version and/or resource fingerprint matches the respective resource name, resource version and/or resource fingerprint stored in a node graph for the resource.

Abstract: A request dispatcher can automatically switch between processing request dispatches in a synchronous mode and an asynchronous mode. Each dispatch can be associated with a unique identification value such as a process ID or Uniform Resource Identifier (URI), historic metrics, and a ruleset. With each execution of the request dispatch, historic metrics can be collected. Metrics can include, but is not limited to, execution duration and/or execution frequency, processor load, memory usage, network input/output, number of dependent dispatches, and the like. Utilizing historic metrics, rules can be constructed for determining which mode to execute the subsequent execution of the dispatch. As such, runtime optimization of Web applications can be further improved.

Abstract: A request dispatcher can automatically switch between processing request dispatches in a synchronous mode and an asynchronous mode. Each dispatch can be associated with a unique identification value such as a process ID or Uniform Resource Identifier (URI), historic metrics, and a ruleset. With each execution of the request dispatch, historic metrics can be collected. Metrics can include, but is not limited to, execution duration and/or execution frequency, processor load, memory usage, network input/output, number of dependent dispatches, and the like. Utilizing historic metrics, rules can be constructed for determining which mode to execute the subsequent execution of the dispatch. As such, runtime optimization of Web applications can be further improved.

Abstract: A request dispatcher can automatically switch between processing request dispatches (e.g., include( )) in a synchronous mode and an asynchronous mode. Each dispatch can be associated with a unique identification value such as a process ID or Uniform Resource Identifier (URI), historic metrics, and a ruleset. With each execution of the request dispatch, historic metrics can be collected. Metrics can include, but is not limited to, execution duration and/or execution frequency, processor load, memory usage, network input/output, number of dependent dispatches, and the like. Utilizing historic metrics, rules can be constructed for determining which mode to execute the subsequent execution of the dispatch. As such, runtime optimization of Web applications can be further improved.

Abstract: A request dispatcher can automatically switch between processing request dispatches (e.g., include( )) in a synchronous mode and an asynchronous mode. Each dispatch can be associated with a unique identification value such as a process ID or Uniform Resource Identifier (URI), historic metrics, and a ruleset. With each execution of the request dispatch, historic metrics can be collected. Metrics can include, but is not limited to, execution duration and/or execution frequency, processor load, memory usage, network input/output, number of dependent dispatches, and the like. Utilizing historic metrics, rules can be constructed for determining which mode to execute the subsequent execution of the dispatch. As such, runtime optimization of Web applications can be further improved.