Browse Prior Art Database

Controlled optimistic processing, especially in a message system

IP.com Disclosure Number: IPCOM000016201D
Original Publication Date: 2002-Sep-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 47K

Publishing Venue

IBM

Abstract

Transactional systems such as IBM's WebSphere* MQ product do not generally permit the reading of uncommitted messages (or other resources).

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

Page 1 of 3

Controlled optimistic processing, especially in a message system

Transactional systems such as IBM's WebSphere* MQ product do not generally permit the reading of uncommitted messages (or other resources).

     This invention discusses an optimistic system that will permit such 'dirty' reads. It still assures overall correct transactional behaviour. It can significantly improve overall application performance; especially latency but also throughput.

Basic principle:

     This invention will be described in WebSphere MQ terms but it applies immediately to other messaging systems. It could also apply to other transactional resource managers, but with fewer benefits and more complications (messaging is simplified by the clear put/get relationship). The WebSphere MQ interface changes are:

Permit an optimistic 'read uncommitted' option on MQGET. This will only be valid for

read under syncpoint. All subsequent syncpointed WebSphere MQ operations until (and including)

MQCMIT, or until (and not including) MQBACK may now return a new return code, MQRC_OPTIMISM_UNFOUNDED. This indicates that a message optimistically read within this transaction has subsequently been backed out. (optional) Provide an MQCONFIRM verb. This will confirm that all earlier optimistic

reads within this transaction have by now been committed (blocking as necessary).

     Once MQRC_OPTIMISM_UNFOUNDED is returned, the transaction is doomed. All further transactional calls will return MQRC_OPTIMISM_UNFOUNDED until the transaction is ended. The system could implicitly end the transaction on the first failed call. This would however cause implicit start of another transaction on the next syncpointed call, which is likely to lead to application programming errors.

Benefits:

     In most application environments, almost all messages that are PUT under syncpoint are later committed. Waiting for these messages is in some sense a waste of time. This can be especially bad where message batching is used for improved throughput (as for example in inter queue manager channels). Consider a case as now:

     Application A sends a message M (via channel C1) to a processing application B. B performs fairly cpu intensive work, and returns a reply (via channel C2). A has waited for the reply, and uses it.

     A now wishes to improve performance, so it batches a set of messages M1, .., Mn and puts them in a single transaction, and then reads the replies when available in a later second transaction. B is also rewritten for performance to read, process and reply to a batch of messages before committing.

     For simplicity, take the case where A, C1, B and C2 all have batches the same size (n). C1 cannot start reading messages from a given batch until A has written the entire batch. B cannot start reading and processing messages until C1 has transferred the whole batch. C2 cannot start transferring replies until B has processed the entire batch. Finally, A cannot start reading replies until C2 has transferred the entire ba...