Parallel Transactions

Parallel transactions is the name used for two or more transactions with the same identifier (primary key).

For instance, when we have the following three transactions where providers and customers are companies with specific attributes:

...we say that they are parallel transactions because they share the identifier CompanyId.

What effect does this have on the design?

As we know, GeneXus designs the database upon standardization criteria, so in this case it will create an only physical table whose attributes will be those resulting from the merged attributes of the three transactions:

 

Therefore, there are three different programs – each with its own rules, events, properties, etc. – but they will share the table where the associated data will be stored.

So, if we execute the “Company” transaction and enter a new company, with code 1234, a record will be inserted in the COMPANY table with primary key value 1234, and the values entered by the user in the CompanyName, CompanyAddress and CompanyPhone attributes (or the values resulting from assignments in the rules) during the execution of “Company”.
What will happen with the other attributes –SupplierPurchases, ClientDiscount, etc. – for this record? They will be empty.

Afterwards, if “Supplier” is executed and 1234 is typed in as the value of CompanyId, there will be a change to Update mode and the values of that record for the attributes in the structure of that transaction will be taken, namely: CompanyName and SupplierPurchases. So, it will be possible to modify these attributes for the referred record.

Likewise, if “Clients” is executed, the user will be able, for example, to modify the values of the CompanyName, ClientDiscount, ClientTotalPurchases and CustomerBalance attributes, and only those in the record accessed.

This is how parallel transactions provide us with a clean way of keeping, in the structure of each transaction, strictly the information with which we want to work in that program, regardless of the data of the same table that can be used in another transaction. 

It should be noted that, because each transaction is an independent object, it is possible to program different rules and events for each of the parallel transactions, so the behavior of each of them may be quite different.

Transactions may be parallel at several levels – here we have just mentioned one-level transactions.

For example, we could have three transactions with the following structures:

 

In this case, there is double parallelism: between the first level of the three transactions, and in the second level of the first two transactions. GeneXus will create the three following tables: