The Commit Process - Integration - Update 44 - Customization & Programming - Hexagon

SmartPlant Integration Customization

Language
English
Product
Integration
Search by Category
Customization & Programming
SmartPlant Foundation / SDx Version
10

The transaction manager uses a two-phase commit process. During each pass all transaction (implements ITransaction) and instructions (implements IInstructionsListener) listeners will be called and given a chance to detect problems that would trigger the need to abort (rollback) the transaction. If no problems are reported, then the methods for the second phase of the transaction are called.

The sequence of calls during the commit process is:

  • The CanInstructionsBeCommitted method is called for each instructions listener. This method gives instructions listeners the chance to abort the transaction.

  • If no CanInstructionsBeCommitted method call returns False, then the CanTransactionBeCommitted method for each transaction listener is called. This method gives each transaction listener the chance to abort the transaction.

  • If all CanTransactionBeCommitted method calls return True, the BeforeProcessInstructions method for each instructions listener is called.

  • The instructions are then processed and constraints on the objects are checked. If any constraint violations are detected, an error message is raised and the transaction is aborted.

  • If the transaction has not been aborted, then the first phase of the two phase commit has been successfully completed.

  • To start the second phase, the AfterProcessInstructions method for each instructions listener is called.

  • The second phase is completed by calling CommitTransaction for each of the transaction listeners.

If a problem occurred during the transaction, then the RollbackTransaction method will be called for each transaction listener.

During the first phase of the commit process, the CanInstructionsBeCommitted method on IInstructionsListener is called. The metadata adapter should use this method to detect any last second problems with the transaction. If a problem is found, then a message should be added to the message container and the metadata adapter should return False. Otherwise it should return True.

If the metadata data store is transactional, then the metadata adapter should register as both a transaction listener and an instructions listener from within its Connect method. If the metadata data store is non-transactional, then the metadata adapter may still want to register as an instructions listener.

If the metadata data store is transactional, then the metadata adapter will probably start its personal transaction from within the CanInstructionsBeCommitted method. From within this method the metadata adapter should issue the appropriate insert, update and delete requests against the metadata data store. The metadata adapter may optionally choose to commit the transaction from within this method or it may choose to do that from within the CanTransactionBeCommitted method.