An Innovative Method for Organizing Incompatible Information at Ideal Time

This study aims at analyzing the problems of transaction management in heterogeneous realtime information systems. It is proposed the use of an algorithm to resolve conflicts in the vague the deadlock transactional situation using construction and reduction of special directed bipartite wait-for graph. Therefore, a reduction algorithm was applied and presented in this article to the count of expectation of transactions G provides the required speed in the conditions of impasses at management of transactions in the heterogeneous distributed information systems of real time. This algorithm proved its efficiency in transaction management.


Introduction
The creation of new means and methods of software for transaction management systems in heterogeneous information systems, providing increase in the quality level and efficiency of access to the distributed data, acquires the increasing relevance in the conditions of creation and combining DBMS of real time [1].While transactions with blocking work there can be a deadlock situation in operational conditions of parallel data exchange, that is a situation at which both transactions wait for each other and cannot come to end.Such condition results in lack of a standard exit from a deadlock, therefore it needs to be distinguished and eliminated.
Methods of resolving a deadlock is to roll back a transaction (victim-transaction) so that other transactions continue their work.After resolving the deadlock, the transaction selected as a victim shall be restarted.
The main problems which arise in case of parallel execution of transactions can be united into four types [3]  During transaction execution, the user sees only coordinated data (the user shouldn't see uncoordinated intermediate data).[1] When in homogeneous DBMS two transactions are executed parallel, the database supports with guarantee the principle of independent execution of transactions, which states that results of transaction execution will be same as if transaction 1 would be executed first, and then transaction 2 or vice versa, transaction 2 the first, and then transaction 1 would be executed.execution of transactions would be the simplest, but such plan is not optimal conditions because of existence of more flexible methods of management of parallel access to databases.
The most widespread mechanism, which is used by commercial DBMS for practical implementation of serializing the transactions, is the blocking mechanism.The simplest option is blocking of an object for all the time of transaction execution.A similar example is reviewed in figure 1.Two transactions conventionally called A and B operate with three tables: T1, T2 and T3.When transaction starts to work with an object it blocks this object, which becomes inaccessible to all other transactions until the end of the transaction, which has blocked ("captures") this object.After transaction completion, all objects blocked by it get unblocked and become available to other transactions.If transaction addresses the blocked object, it remains pending until this object gets unblocked then it can continue processing this object.Therefore, transaction B waits for unlocking of table T2 by transaction A. Above rectangles there is conditional time of operations execution.
Generally, when performing a transaction gets exclusive access to DB objects with which it works.In this case, other transactions don't get access to DBMS objects until the end of transaction.Such mechanism really eliminates all problems listed above: unsaved changes, unconfirmed data, uncoordinated data, and phantom lines.However, such blocking creates new problems -a delay of transaction performance because of blocking [3] Considering the existing types of the conflicts between two parallel transactions.The following types can be separated: -W-W -transaction 2 tries to change the object changed by not ended transaction 1; -R-W -transaction 2 tries to change the object read by not ended transaction 1; -W-R -transaction 2 tries to read the object changed by not ended transaction 1.
The blockings called also synchronizing object can be applied to different type of objects.The greatest object to lock can be entire database; however, this type of lock will make a DB In a number of the DBMS, lock at page level is realized.In this case, the DBMS locks only individual pages on a disk when transaction addresses them.In the example, it is considered that transaction A locks first the object, and then transaction B tries to access it.Here is an example.Let transaction A first to block hard the table 1, and then to block hard the table 2. Transaction B, on the contrary, at first blocks hard the table 2, and then blocks hard the table 1.If both of these transactions have begun working at the same time, then after performance of modification operations by the first subjects of each transaction both of them will pend infinitely: transaction A will wait for completion of work of transaction B and unblocking of table 2, and transaction B will wait also without results for completion of work of transaction A and unblocking of table 1 (figure 3).Situations can be much more difficult  Let's consider a situation of the synchronous deadlock: transactions T1 and T2 set exclusive locks of objects O1 and O2 respectively; after this T1 requires joint lock of object O2, and T2 requires joint lock of object O1; no one of these requirements of lock can't be satisfied, therefore, no transaction can proceed; therefore, exclusive locks of objects will never be removed, and requirements of joint locks won't be met.
As deadlocks are possible and no natural outcome from lockup exists, these situations need to be found and synthetically eliminated within the constructed coordinator of transactions of the In this case, the procedure of reduction is that first of all from the wait-for graph G all those directed lines are being deleted which go from top-transactions and to which no directed lines from top-objects enter.Besides, those directed lines are removed which enter to peaktransactions and from which no directed lines conducting to peak-objects start from [3].For those peak-objects for which there is no entering directed lines but there are outgoing ones, orientation of one of outgoing directed lines (chosen arbitrarily) changes to an opposite [2].
After performance of the first step of a reduction of mirror algorithm the subsequent steps are being performed until the removal of directed lines stops.
In case of need of deadlock destruction, the build transaction coordinator chooses a transaction victim Tk in a random way and makes its roll-back, and afterwards resends it.In fig.6, the reduction implementation algorithm in wait-for graph in conditions of transaction management by a real-time DBMS is provided [3].

Results
The following results were obtained: 1. Architecture of web-based applications for multiprocessor and cluster solutions that are scalable and provides high performance when inter-module interaction in database.

2.
Hierarchical model of access to data and internal information exchange in a web-based interface that provides rapid generation of data based on queries to the database information environment.
3. The concept of transaction was extended to information systems in general, not just to DBMS as a part of such systems.

4.
This solution provides enhanced operational efficiency allowing several applications to work jointly.

5.
This algorithm proved its efficiency in transaction management.
: unsaved changes (the situation occurs if two transactions change simultaneously the same record in DBMS); problems of the intermediate data (the situation arises in case of formation of intermediate data on an object, at a stage of executed parallel

Figure 1 :
Figure 1: Blocking at simultaneous performance of two transactions

Vol: 14
No:1, January 2018 DOI: http://dx.doi.org/10.24237/djps.1401.328AP-ISSN: 2222-8373 E-ISSN: 2518-9255unavailable to all applications, which work with this DBMS.The next type of subject for blocking are tables.Transaction, which works with the table, blocks it for all the time of transaction execution.This type of blocking is more preferable than previous because it allows carrying out in parallel transactions, which work with other tables.

(
synchronizing captures): -The joint mode of blockingthe soft or divided blocking known as S (Shared).This mode means the dividable capture of object and is required for performance of object reading operation.The objects thus blocked don't change during transaction execution and are available to other transactions also, but only in reading mode; -The exclusive mode of blocking -hard, or exclusive, blocking knows as X (exclusive).This mode of blocking assumes exclusive capture of object and is required for performing of entering, removal and modification operations.The objects blocked by this type of blocking actually remain in the exclusive mode of processing and are inaccessible for other transactions until completion of work of this transaction.Objects capturing by several transactions are compatible for reading, namely several transactions are allowed to read the same object, object capture by one transaction for reading is incompatible with capture by other transaction of the same object for record, and captures Vol: 14 No:1, January 2018 DOI: http://dx.doi.org/10.24237/djps.1401.328AP-ISSN: 2222-8373 E-ISSN: 2518-9255 of one object by different transactions for record are incompatible [2].Rules of compatibility of captures of one object by different transactions are presented in the table.

Figure 2 :Figure 3 :
Figure 2: Use of hard and soft blocking

[ 2 ]
. The number of mutually blocked transactions can be much more.The basis for deadlock detection is the implementation of operations in the transaction wait-for graph.A transaction wait-for graph is the directed bipartite graph G= (W, E) in which all tops are grouped into two types -the tops corresponding to U transactions and the tops corresponding to V blocking subjects.At the same time performance of the following conditions is important U^V = W, |U |> 0, |V |> 0 so no peak in U isn't connected to peaks in U and any top in V isn't connected to peaks in V.In the considered graph the directed lines S connect only peak-transactions to peak-objects.The directed line from peak-transaction to Si peak-object exists if and only if for this transaction there is a satisfied blocking of this object[1].The directed line from Si peak-object to top of transaction Sj exists if and only if when this transaction expects satisfaction of blocking inquiry for this object.It is easy to show that in system there is a deadlock condition in that and only that case when in transaction expectation graph G there is Vol: 14 No:1, January 2018 DOI: http://dx.doi.org/10.24237/djps.1401.328AP-ISSN: 2222-8373 E-ISSN: 2518-9255 at least one cycle.The simplest example of the transactions expectation graph with a cycle is shown in figure 4.

Figure 4 :
Figure 4: A situation of the synchronizing deadlock between transactions T1 and T2

Figure 5 :
Figure 5: Initial condition of expectation count

Figure 6 :
Figure 6: The block diagram of an algorithm of a reduction in the column of expectation

Table 1 :
Rules of application of hard and soft blocking of transactions [1]s type of blocking is softer and allows different transactions to work even with the same table if they address different pages of data.In some DBMS, blocking at the level of lines is possible; however, such mechanism of blocking requires additional costs on support of this type of blocking.For increase in parallelism of transactions execution, the combination of different types of synchronizing captures is used[1].Two types of blocking are considered