3.3.5.6 SubmitChanges Event Processing

The server receives an rdsSubmitChangesRequest message from the client. The server will process out the parameters and fashion a call to the SubmitChanges method. The parameters are processed according to the algorithm described in section 3.3.1.2.<86>

The RDS Transport Protocol server SubmitChanges method MUST go through the TableGram, and for each update request in the TableGram apply the algorithm detailed in section 3.3.1.2 to determine if the update is an active or stale update. If the update request is a stale update, the method returns rdsMethodResponseError with an SCODE of %x09.00.02.80 (DispEException) and an SCODE2 of %x38.0E.04.80 (DBEConcurrencyViolation) in place of rdsSubmitChangesResponse. If the update is active, the update is sent to the data store.

For each insert message in the TableGram, the RDS Transport Protocol server MUST execute a SQL command on the backend database to insert the new record. If the backend data store returns an error, the RDS Transport Protocol server returns rdsMethodResponseError with an SCODE of %x09.00.02.80 (DispEException) and an SCODE2 of %x38.0E.04.80 (DBEConcurrencyViolation) in place of rdsSubmitChangesResponse.

For each delete message in a TableGram, the RDS Transport Protocol server MUST execute a SQL command on the backend database to delete the requested record. If the backend data store returns an error, the RDS Transport Protocol server returns rdsMethodResponseError <87> with an SCODE of %x09.00.02.80 (DispEException) and an SCODE2 of %x38.0E.04.80 (DBEConcurrencyViolation) in place of rdsSubmitChangesResponse.

The RDS Transport Protocol server SHOULD<88> do all of the above in a single transaction.

The RDS Transport Protocol server MUST then construct an rdsSubmitChangesResponse. The contents of the rdsSubmitChangesResponse are sent back to the client in the reply.