Browse Prior Art Database

Locking prioritisation to support Qualities of Service in cloud-based messaging service instances Disclosure Number: IPCOM000243027D
Publication Date: 2015-Sep-09
Document File: 2 page(s) / 55K

Publishing Venue

The Prior Art Database


Taking low level prioritised locking concepts and applying them to a wider distributed system to allow for a more dynamically efficient interaction of the various components.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 49% of the total text.

Page 01 of 2

Locking prioritisation to support Qualities of Service in cloud-based messaging service instances

In a cloud-based messaging provider, a number of service instances can be operating concurrently, providing similar, related services to end applications. Over time, different instances might be created, started, stopped or destroyed in response to changes in the demands of the running end applications.

    These changes might be to create and start a new service instance that is the same as an existing one in order to scale up in response to an increase in the throughput of existing applications. Alternatively, a new service could be created that is intended to provide messaging capability for a prioritised, or preferred, set of applications. That is, the messaging provider could provide different tiers of quality (ToQ) to different users of the services.

Provision of the messaging functions at each ToQ to end applications will potentially use different components of the messaging provider (for example, a ToQ that provides messaging within distributed transactions will require access to a transaction coordinating component, which will not be required by a ToQ that only

provides non-persistent messaging). However, many parts of the messaging provider will provide functionality that is required at all ToQs (for example, a component that constructs a set of header information to attach to messages when they are sent).

    By default, concurrent messaging service instances that are providing different ToQs would all compete for access to the common messaging provider components when needed. These components would require a locking mechanism to control and serialize access to the component and its associated resources. A prioritised locking mechanism could be utilised to coordinate the frequency and ordering of access to the component to better support the different ToQs.

    Within a cloud-based messaging provider, certain components must be controlled in order to avoid simultaneous use by multiple applications or instances of the service. This will usually be accomplished by a resource lock that threads associated with each instance must obtain before it can access the controlled resources. Typically, this lock is allocated to threads on a first come, first served basis, and threads that try to obtain the lock while it is held by a different thread are blocked and then given the lock in order as it becomes available. This can create a bottleneck in performance when multiple service instances are active.

    A priority locking system could be utilised within each service instance to optimise the order in which work is performed within that instance to maximise message throughput. This invention proposes and extension to that prioritisation to allow certain service instances to obtain access to different components within the messaging provider framework in preference to other instances in order to provide different ToQs.

    When a message is sent, a numbe...