Hmm, yes, sorry for the confusion. The docs are correct, the presence of an update operation in the queue will be enough to bundle everything into a transaction.
However, this only applies to real queues that come from the client as a series of DSRequests enclosed by calls to startQueue() and sendQueue(). In this case, the makeup of the queue is known in advance and is available to the RPCManager for the entire lifetime of the queue of requests it is managing.
Your case is different. It is not a real queue, it is just a number of server-created DSRequests that share an RPCManager because your code manually applies the RPCManager to the requests. No attempt is made to include DSRequests added in this ad hoc way when deciding whether a transaction policy like ANY_CHANGE is applicable to a given DSRequest, so we understand why you are getting the results you are. However, before we state categorically that this is the correct behavior, we want to clarify why this didn't also happen with release 3.1.
We will post back on this thread when we have investigated.
However, this only applies to real queues that come from the client as a series of DSRequests enclosed by calls to startQueue() and sendQueue(). In this case, the makeup of the queue is known in advance and is available to the RPCManager for the entire lifetime of the queue of requests it is managing.
Your case is different. It is not a real queue, it is just a number of server-created DSRequests that share an RPCManager because your code manually applies the RPCManager to the requests. No attempt is made to include DSRequests added in this ad hoc way when deciding whether a transaction policy like ANY_CHANGE is applicable to a given DSRequest, so we understand why you are getting the results you are. However, before we state categorically that this is the correct behavior, we want to clarify why this didn't also happen with release 3.1.
We will post back on this thread when we have investigated.
Comment