SQL Guide : solidDB® SQL statements : MESSAGE : MESSAGE GET REPLY
  
MESSAGE GET REPLY
MESSAGE unique_message_name GET REPLY
[TIMEOUT {FOREVER | seconds}]
[COMMITBLOCK block_size_in_rows]
[NO EXECUTE]
[{OPTIMISTIC | PESSIMISTIC}]
Usage
The MESSAGE GET REPLY statement requests a message from the master database, if a reply to a sent message has not been received by the MESSAGE FORWARD statement. The MESSAGE GET REPLY statement is applicable only in advanced replication configurations. It can only be issued on the replica databases.
TIMEOUT defines how long the replica waits for the reply from the master. For example, if the master database takes a long time to start due to, for example, a server restart, the message reply to replica can time out. To recover, reissue the MESSAGE GET REPLY command and set the timeout to a larger value or FOREVER.
If the reply message contains REFRESHes of large publications, the size of the REFRESH commit block, that is, the number of rows that are committed in one transaction, can be limited using the COMMITBLOCK property. This has a positive impact on the performance of the replica database. It is recommended that there are no online users in the database when the COMMITBLOCK property is in use.
If the execution of a reply message with the COMMITBLOCK property fails in the replica database, it cannot be re-executed. The failed message must be deleted from the replica database and refreshed from the master database.
If NO EXECUTE is specified, when the reply message is available at the master, it is only read and stored for later execution. Otherwise, the reply message is downloaded from the master and executed in the same statement. Using NO EXECUTE reduces bottlenecks in communication lines by allowing reply messages for later execution in different transactions.
You can define the reply message to use table-level pessimistic locking when it is initially executed. If the PESSIMISTIC mode is specified, all other concurrent access to the table affected is blocked until the synchronization message has completed. If the optimistic mode is used, the MESSAGE GET REPLY operation may fail due to a concurrency conflict.
When a transaction acquires an exclusive lock to a table, the General.TableLockWaitTimeout parameter setting determines the wait period of the transaction after which the exclusive or shared lock is released.
If a reply message fails in delivery due to a communication error (without COMMITBLOCK), you must explicitly use the MESSAGE GET REPLY to resend the message. Once resent, MESSAGE GET REPLY re-executes the message.
Note When working with the messages, the autocommit mode must be switched off.
Result set
MESSAGE GET REPLY returns a result set table. The returned result set is the same as with command MESSAGE EXECUTE.
The columns of the result set are as follows:
Column Name
Description
Partno
Message part number
Type
The type of result set row. Possible types are:
0: Message part start
1: This type is not in use
2: The message was a propagation message and the status of that operation is stored in the return message
3: Task
4: Subscription task
5: Type of refresh (FULL or INCREMENTAL)
6: MESSAGE DELETE status
Masterid
Master ID
Msgid
Message ID
Errcode
Message error code. Zero if successful.
Errstr
Message error string. NULL is successful.
Insertcount
Number of inserted rows to replica.
Type=3: Total number of insert
Type=4: Row inserts restored from replica history to replica base table
Type=5: Insert operations received from master
Deletecount
Type = 3: Total number of deletes
Type = 4: Row deletes restored from replica base table
Type = 5: Delete operations received from master
Bytecount
Size of message in bytes. Indicated in result received from command MESSAGE END. Otherwise 0.
Info
Information of the current task.
 
Type = 0: then Message name
 
Type = 3: Publication name
 
Type = 4: Table name
 
Type = 5: FULL/INCREMENTAL
Return values
Fatal errors in transaction propagation abort the message and return an error code to the replica. To propagate the aborted message, you need to correct the fatal errors and restart the message with command MESSAGE FROM REPLICA EXECUTE.
If a REFRESH fails in the master, an error message about the failed REFRESH is added to the result set. Other parts of the message are executed normally. The failed REFRESH must be REFRESHed from the master in a separate synchronization message.
If a REFRESH (that is, the execution of the reply message) fails in the replica, the message is still available in the replica database and can be restarted with the MESSAGE msg_name EXECUTE command.
Return values from replica
Error code
Description
13XXX
Table level error
13124
User id num not found
This message is generated, for example, if the user has been dropped.
10006
Concurrency conflict (simultaneous other operation)
13047
No privilege for operation
13056
Insert not allowed for pseudo column
21XXX
Communication error
25005
Message message_name is already active
25013
Message name message_name not found
25018
Illegal message state
In the replica, the message can only be executed using the MESSAGE GET REPLY statement if the message is forwarded to the master.
25024
Master not defined
25026
Not a valid master user
25031
Transaction is active, operation failed
25035
Message message_name is in use. A user is currently creating or forwarding this message.
25036
Publication publication_name not found or publication version mismatch
25040
User id user_id is not found
While executing a message reply, an attempt to map a master user to a local replica id failed.
25041
Subscription to publication publication_name not found
25048
Publication publication_name request info not found
25054
Table table_name is not set for synchronization history
25056
Autocommit not allowed
25057
Already registered to master master_name
25060
Column column_name does not exist on publication publication_name resultset in table table_name
Return values from master
Error code
Description
13XXX
Table level error
13124
User id num not found
This message is generated, for example, if the user has been dropped.
25012
Message reply timed out
25016
Message not found, replica id replica-id, message id message-id
25043
Reply message is too long (size_of_messages bytes). Maximum is set to max_message_size bytes.
25056
Autocommit not allowed
Examples
MESSAGE MyMessage001 GET REPLY TIMEOUT 120
MESSAGE MyMessage001 GET REPLY TIMEOUT 300 COMMITBLOCK 1000
Related reference
MESSAGE FROM REPLICA EXECUTE
REFRESH
See also
MESSAGE