MQ: persistence on the client side? - Websphere

This is a discussion on MQ: persistence on the client side? - Websphere ; Hi, We are new to MQ persistence & assurance of delivery (we've been using MQ, but assurance of delivery wasn't an issue before). Now, we need persistence, assurance of delivery, and transactions - starting *from the client machine*. I.e: when ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: MQ: persistence on the client side?

  1. MQ: persistence on the client side?

    Hi,

    We are new to MQ persistence & assurance of delivery
    (we've been using MQ, but assurance of delivery wasn't an issue before).

    Now, we need persistence, assurance of delivery, and transactions - starting *from the client machine*.
    I.e: when the client invokes 'MQ PUT', and there's a temporary network failure, we'd like the message to be:
    1) Stored on the client machine's hard-drive
    2) And retransmitted when the network recovers.
    3) If possible, we'd also like to view pending messages (waiting to be retransmitted)

    Our question: is this supported by *MQ client* installation ?
    Or does it require us to install an *MQ Queue manager* on the client machine?

    Thanks.

  2. Re: MQ: persistence on the client side?

    MQ Client does not support local storage or retry / retransmission of messages, so you'll need to go for MQ Server to get that capability.

  3. Re: MQ: persistence on the client side?

    This is a loaded question, since you raise the topics (1) persistence, (2) transactions, and (3) delivery assurance all in 1 breath.

    Of course, persistence and transaction processing (Units of Work (UOW)) are methods to accomplishing assured delivery.

    The previous poster is correct, you will probably have great difficuly accomplishing all of your goals as a simple client.

    You can install Extendeded Transactional Client support - please see
    http://www-01.ibm.com/software/integ...ansclient.html for complete details. Since the license charges are the same as for a qmgr, some installation opt to install the server instead and get all the benefits of a full-scale server - as well as the headahces, such as maintaining the server, the rolling transaction log files, etc.

    Assurance of delivery is what WMQ is all about, but there things you can do to help it do its job better. Look at delivery-notification, as an example of something you can build into your application; don't forget positive AND negative reports; you want to know about the message's final disposition, no questions asked!

    Good luck, let us know what you decide.
    Dave

  4. Re: MQ: persistence on the client side?

    know about the message's final disposition, no questions asked!

    I beg to disagree. Notification (aka MQ Reports) does not help MQ to deliver
    messages. It does not change quality of service. If anything, it hinders MQ
    by creating a larger volume of messages that it has to process.

    MQ Report messages (confirmation of delivery, confirmation of arrival, expiration, negative acknowledgement, positive acknowledgement) travel the same paths as your application messages and so can only be as reliable as the original message. MQ Report messages may give a sending application a warm and fuzzy feeling that MQ has done something, but they should not be relied upon, and they go against the paradigm of asynchronous message programming.

    Feel free to discuss further. Glenn.

+ Reply to Thread