Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Distributed Multi-Task Transaction Service

IP.com Disclosure Number: IPCOM000021813D
Original Publication Date: 2004-Mar-25
Included in the Prior Art Database: 2004-Mar-25
Document File: 5 page(s) / 169K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

The principal purpose of this new system is to solve Distributed Multithreading/Multitasking problems when executing tasks using the same resources (evoked by caller operations) that lead to database corruption and to classical deadlock situations. In fact, the Distributed Multi-Task Transaction Service (DMTTS), based on a reservation mechanism, avoids database corruption and deadlocks due to concurrent access of two or more tasks to the same system-wide shared resources. Furthermore, when a task starts its execution it has the guarantee of completion because all the needed resources will be available and not shared by other task in execution. There are some approaches to this problem which are applied to monolithic systems. In a distributed multi-process environment expensive additional systems, known as transaction managers, are needed if one wants to take advantage of distributed parallel execution. The proposal in the present IR (Internal Representation) avoids that two or more current tasks will not be blocked when a common resource is used by other task. Note that in the worst case they can be blocked waiting for the same resources locked by the other task. Each task determines which entities will be involved in the correspondent use case/operation (including the entities used by the tasks and subtasks) and mark them as reserved in order to not being changed or deleted by other concurrent task. The objects accessed by a task can be local or in a different server running their own DMTTS that communicates with others DMTTS to support objects distribution.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 5

S

Distributed Multi-Task Transaction Service

Idea: João Paulo Pereira, PT-Alfragide; José Pedro Castanheira, PT-Alfragide

The principal purpose of this new system is to solve Distributed Multithreading/Multitasking problems when executing tasks using the same resources (evoked by caller operations) that lead to database corruption and to classical deadlock situations. In fact, the Distributed Multi-Task Transaction Service (DMTTS), based on a reservation mechanism, avoids database corruption and deadlocks due to concurrent access of two or more tasks to the same system-wide shared resources. Furthermore, when a task starts its execution it has the guarantee of completion because all the needed resources will be available and not shared by other task in execution.

There are some approaches to this problem which are applied to monolithic systems. In a distributed multi-process environment expensive additional systems, known as transaction managers, are needed if one wants to take advantage of distributed parallel execution.

The proposal in the present IR (Internal Representation) avoids that two or more current tasks will not be blocked when a common resource is used by other task. Note that in the worst case they can be blocked waiting for the same resources locked by the other task. Each task determines which entities will be involved in the correspondent use case/operation (including the entities used by the tasks and subtasks) and mark them as reserved in order to not being changed or deleted by other concurrent task. The objects accessed by a task can be local or in a different server running their own DMTTS that communicates with others DMTTS to support objects distribution.

The DMTTS is based on three functional components: the Dispatcher, the Location Service and the Thread Manager. Each caller operation is split in two transaction steps, T1 and T2, each one having its own recovery mechanisms at a system crash or failure. Caller operation information is stored in T1 and is dispatched to execution by Dispatcher. Then, the T2 is executed.

The Dispatcher is a component that comprises the Task Queue and the Hash Table encapsulating all

the synchronization mechanisms used to serialize the access to shared resources. The Task Queue is where all tasks are put in order to be executed. The Hash Table holds all entities in use by a task under execution. A task in queue needing to lock one or more entities that are present in Hash Table due to another task under execution cannot be executed.

The Location Service is used to support a distributed environment allowing the communication

between DMTTS on distinct servers. At run-time, it locates the remote DMTTS where a particular entity was previously created and checks if it is currently in use or reserved in the remote server.

The Thread Manager manages a thread poll that invokes methods on the Dispatcher. The number of

threads in the system is configurable at start-up (all with the same...