Browse Prior Art Database

System and Method for propagating quality of service in a distributed transaction environment Disclosure Number: IPCOM000243770D
Publication Date: 2015-Oct-16
Document File: 9 page(s) / 147K

Publishing Venue

The Prior Art Database


A method for providing Quality-of-Service by all nodes in the distributed transaction systems based on the client's properties or profile. The QoS might include prioritizing the transaction or client information based load balancing at every node of the transaction system, which can implement their unique algorithm. But provide the required QoS for the client request.

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

Page 01 of 9

System and Method for propagating quality of service in a distributed transaction environment

Most of the products (Transaction Manager, Resource Manager) in the distributed transaction domain have their own proprietary workload balance, scheduling and prioritisation of workloads. However as part of a Business solution, each of the them (middleware or resource environment) has to be tuned independently as per each products guidelines. For a solution seeker / buyer, this will be a huge effort.

In the current age of 'world is a global village', the service industry, banking, on-line trading, 'branches of brick and mortar shops spreading across the world', a buyer would prefer the Transaction solution with all its constituent products be tied up with their business/application logic. So that they can easily understand, tune, trouble shoot problems. I.e., the solution portfolio need to be sensitive to the data to offer better Quality-Of-Service'.

For example, consider the scenario of walmart, which has varied trading platforms like online shopping, shop with walmart's mobile application, brick and mortar shops, etc. Here one might want to have the following priority for any transactions:

1. Point of Sales => High. Customers can't be lined-up for want of faster response.

2. Mobile app => Medium. A dedicated and returning customer

3. Tablet app => Average. A dedicated, returning but leisurely shopper

4. On-line shopping => Low. Returning customer. May not be dedicated

In this case, all the parts (products) of the transaction solution has to fulfil this requirement. However due to the proprietary algorithm / implementation in each product, it may not be possible to get the desired priority. Especially when there is a requirement to consider the client information / data and prioritize / load balance.

Following is a hypothetical scenario in the transaction solution involving various products.


Page 02 of 9

In the following example, though PoS request is of High priority as per business requirement, it is lined-up behind less priority requests. i.e., exisitng logic may not be guaranteed to service PoS request with high priority.


Page 03 of 9

Problem Description:

Most of the TMs and RMs have their own proprietary workload balance and priority logic. Each of them may not be effectively t...