The commit service acts as a single place of record to help the application decide whether the transaction should be committed or canceled.
If the SQL Server cannot communicate with the server functioning as the commit service, it retries the connection every minute. The current command displayed in the command column of sp_who for any transaction still attempting to connect to the commit service server is PREPARE TRANSACTION. The system administrator can use the KILL command to stop the server's attempts to retry the connection. If a connection cannot be established within 1 minute, the database is marked as "not recovered" and an attempt is made to recover the next database. When the commit service server is available again, shutting down the server with the unrecovered database and bringing the server back up again enables the recovery of the transaction in doubt.
The role of the application is to deliver the Transact-SQL statements to the SQL Servers in the proper order, using the proper DB-Library functions. The role of the commit service is to provide a single place where the commit/rollback status is maintained. The SQL Servers communicate with the commit service only if a failure happens during the two-phase commit.
To keep transaction records, the commit service needs its own DBPROCESS structure, separate from those used in the distributed transaction. Note, however, that the server handling the commit service also can be one of the servers participating in the transaction, as long as the commit service has its own DBPROCESS. In fact, all the servers in the transaction could be one and the same, although then you would not need this special library.