Commits a transaction. This operation flushes all the pending changes to the server side.
 
   Request: (tx-id:int)(using-tx-log:byte)(tx-entry)*(0-byte indicating end-of-records)
   tx-entry: (operation-type:byte)(cluster-id:short)(cluster-position:long)(record-type:byte)(entry-content)

   entry-content for CREATE: (record-content:bytes)
   entry-content for UPDATE: (version:record-version)(content-changed:boolean)(record-content:bytes)
   entry-content for DELETE: (version:record-version)

   Response: (created-record-count:int)[(client-specified-cluster-id:short)(client-specified-cluster-position:long)(created-cluster-id:short)(created-cluster-position:long)]*(updated-record-count:int)[(updated-cluster-id:short)(updated-cluster-position:long)(new-record-version:int)]*(count-of-collection-changes:int)[(uuid-most-sig-bits:long)(uuid-least-sig-bits:long)(updated-file-id:long)(updated-page-index:long)(updated-page-offset:int)]*
  
Where:
  • tx-id is the Transaction's Id
  • use-tx-log tells if the server must use the Transaction Log to recover the transaction. 1 = true, 0 = false
  • operation-type can be:
    • 1, for UPDATES
    • 2, for DELETES
    • 3, for CREATIONS
  • record-content depends on the operation type:
    • For UPDATED (1): (original-record-version:int)(record-content:bytes)
    • For DELETED (2): (original-record-version:int)
    • For CREATED (3): (record-content:bytes)
This response contains two parts: a map of 'temporary' client-generated record ids to 'real' server-provided record ids for each CREATED record, and a map of UPDATED record ids to update record-versions. Look at Optimistic Transaction to know how temporary RecordIDs are managed. The last part or response is referred to RidBag management. Take a look at the main page for more details.
Inheritance: extends PhpOrient\Protocols\Binary\Abstracts\Operation, use trait PhpOrient\Protocols\Binary\Abstracts\NeedDBOpenedTrait
 public function rollBack()
 {
     $this->transaction->rollback();
 }