Browse Prior Art Database

System choice of serial transaction batching Disclosure Number: IPCOM000016055D
Original Publication Date: 2002-Aug-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 48K

Publishing Venue




This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 3

System choice of serial transaction batching


It is standard procedure to batch a series of sequential actions (subtransactions) into transaction batch. The batch boundary is decided by the application based on number of subtransactions, time since start of batch, or total 'size' of accumulated transaction. This applies in many messaging and database application areas such as:
1. Java* Messaging Service (JMS)/WebSphere** MQ batch programs (as described above)
2. JMS/MQSeries**with 'implicit' looping/transactions. e.g.

the driver for MessageDrivenBeans,

the WebSphere MQ Integrator MQInput node.
3. database 'batch' programs PROBLEM

     The problem is that the application does not have enough knowledge of the server operation to know the best batch size, etc. SOLUTION

     The commit interface is extended with an 'optional' flag. CMIT(optional) also implies a new BEGIN.

Sample program

It is described it terms of an example MQ server program.

typical MQ Server loop (pseudocode)


MQBEGIN for i=1 step 1

// every time round the loop, perform operation on one item MQGET request
on timeout, break perform task (maybe including database update, etc) MQPUT response

// Every batchsize items, do a commit. // This will commit the GETs/ database updates and GETs // for all the last batchsize items. if (i mod batchsize == 0)

MQCMIT MQBEGIN // and get ready for next batch

     end if
end for

// Make sure final (partial) batch is committed // May be anything from 0 to batchsize-1 items. MQCMIT


Page 2 of 3

Sample program, proposed solution


MQBEGIN for i=1 step 1

     MQGET request on timeout, break perform task (maybe including database update, etc) MQPUT response
end if
end for

     The implementation of the resource manager (and maybe transaction coordinator) will decide on each CMIT(optional) whether or not to perform a commit. This will be based on a combination of application knowledge (how old/large is the transaction so far), and a...