Is anyone using wM6.5 WebSphere MQ Adapter 6.5?

Hi all,

Wondering if anyone in the community is using the MQ adapter. If so, any general comments about reliability and usage? Approximately how many documents do you pass through the adapter in one month? We are possibly looking to convert a system that is currently doing 700K documents per month.


Carl Kennedy

Based on your requirement for reliability purpose you may have to choose/define Transactional based MQ connections (for Listen/Get/Put) queue handlers and implement the logic using WmART transactional services to handle commit/rollback facilities that makes more guranteed/error handling/managing server breakdowns etc…So Error handling/tracking transactions is the critical with the use of any adapter P2P,Pub-Sub model development.

WebSphere_MQ_Adapter is robust/handling batches/volumes like any other existing adapters developed based on the ART,Pub-Sub framework.


When you go for Transactional based MQ Connections, you may not need to use WmART services to handle commit/rollback facilities.

WebSphere Transactional MQ Connections by itself will handle fully commit/rollback features.

I agree with you…but

A single transaction context can contain no more than one LOCAL_TRANSACTION connection. If your flow contains adapter services that use more then one LOCAL_TRANSACTION connection, you must use explicit transactions that is where you need WmART services (start,commit,rollback calls) explicitly…obviously at some point in the flows there are chances to invoke multiple PUT adapter services and so to handle error points the transactional management plays critical role.


I agree… When there is more than one LOCAL_TRANSACTION, start, commit and rollback calls are required…

Just a hint: When invoking multiple PUT adapter services in flow, explicit transaction is required… But when invoking a single PUT Adapter multiple times in a flow, explicit transaction is not required in Transactional MQ Connections.


Yes…we are on the same page…

Hi RMG, Senthil - Question for you. Let’s say I use a non-transactional connection and GET a msg from a queue. If that GET MQ adapter service fails, will the message be rolled back onto the queue automatically?

What about a PUT with the same non-transactional connection? If the PUT fails, I’m guessing nothing gets PUT onto the queue.

I think you have mistyped as Non Transactional connection…

In case of Transactional connection, when there is a failure while getting the message from queue, the message will be rolled back to the queue

Same with Put message, when there is a failure, the message will not be placed into the queue.

In case of normal WebSphere MQ Connection which is Non-Transactional, explicit ART services are required to commit and rollback…


Thanks for your response Senthil.

I may be misunderstanding transactionality as it relates to the MQ Adapter then; because I did mean to say non-transactional.

I am very familiar with the JDBC Adapter so I think I’m trying to extend its “pattern” to help me understand how MQ Adapter handles transactionality. With the JDBC Adapter, if you use a NO_TRANSACTION connection type, the adapter service commits or rolls back implicitly depending on whether that adapter service fails or succeeds.

I guess my question is this: Does MQ Adapter handle a “non-transactional” connection the same way as JDBC Adapter? Or should I not try to use this comparison to help me understand transactionality as it relates to MQ Adapter?

In JDBC, if transaction type is set to NO_TRANSACTION, it commits or rollbacks depending upon success or failure (for a single adapter service call)

In MQ, Non Transactional connection’ means, transactions are not maintained…

In Non Transactional Connection, once a message is taken from the queue, the message is lost, no matter if the transaction is success/failure.

In Transactional Connection, the message disappears only if the service executes without any error after retrieving the message from queue… If there is any failure, message remains in the queue…


Ok … so JDBC and MQ Adapters are a little different. But what you described makes sense. Thanks for the explanation!

Hi All,
I’m not sure this is right thread to post my issue…but i need information on below issue…
can we use JDBC and MQ adapter services in one flow service???
JDBC Connection is configured with LOCAL_TRANSACTION and
MQ connection is configured with ROLLBACK and it is a traditional transaction.


Yes, this is possible

hi asish,
thx for ur reponse…
my requirement is like this …first we are updating the database and after that invoking put MQ adapter service. If put MQ adapter service is failed then database update should rollback.

Pls could you tell me how to achieve this.


Assuming you have multiple db calls to the same db and a single MQ put, here’s how to code it. The db conn type should be LOCAL_TRANSACTION and MQ conn should be non transactional.


Whoops, indents didnt’ come across on last post. I trust you can figure that part out.

can we use the same pattern of coding for the DB Location Transaction and MQ Transactional Connection.
I coded like below

Main Service :

Main Seq
Try Seq
select adapter service
update adapter service
“Invoking Sub Flow Service”
Commit Transaction (output Start Transaction is mapped as input)
Catch Seq
Rollback Transaction (output Start Transaction is mapped as input)
exit flow on failure

Sub Service code : “Invoking Sub Flow Service”

Main Seq
Try Seq
putMQ adapter service
Commit Transaction (output Start Transaction is mapped as input)
Catch Seq
rollback transaction (output Start Transaction is mapped as input)
exit flow on failure

But I’m getting error :

" [ART.114.302] Adapter Runtime (Transaction): Error while committing transaction 1180. The transaction in progress is 1179.
3/23/2009 5:34:04 PM [ART.114.302] Adapter Runtime (Transaction): Error while committing transaction 1180. The transaction in progress is 1179. "

can u tell me how to resolve this issue


Hi Durga - The first question is: why do you need transactionality around a single MQ PUT?

Hi All,

this thread has been quite instructive. I have designed the following flow:

    1    Service Invoke  INVOKE startTransaction
        2   Sequence SEQUENCE
                2.1   Sequence SEQUENCE (try)
                        2.11   Service Invoke INVOKE put2
                        2.12   Service Invoke INVOKE put1
                        2.13   Service Invoke INVOKE commitTransaction
                        2.14   Map MAP
                2.2   Sequence SEQUENCE (catch)
                        2.21   Service Invoke INVOKE getLastError
                        2.22   Service Invoke INVOKE testForServiceRetry
                        2.23   Service Invoke INVOKE rollbackTransaction
                        2.24   Map MAP
        3   Branch BRANCH on '/throwRetryException'
                3.1   Service Invoke true: INVOKE throwExceptionForRetry
                3.2   Exit false: EXIT '$flow' (signal Failure) 

put1 and put2 are transaction connections to a local MQ Queue.

When I run this service I get the following exception:

[ART.114.303] Adapter Runtime (Transaction): Unable to commit transaction.
[ART.117.4015] Adapter Runtime (Adapter Service): Error(s) occurred while closing adapter connections.
[ART.117.4015] Adapter Runtime (Adapter Service): Error(s) occurred while closing adapter connections.

In the Server log,

[123]2009-10-07 11:33:14 EST [SCC.0121.0034E] commit failed: more than 1 local trans enlisted. xid = [FormatId=45744, GlobalId=machinename/1253684687875, BranchQual=1] rxid = {2}
[124]2009-10-07 11:33:14 EST [SCC.0121.0026E] delisted transaction commit failed: java.lang.IllegalStateException: commit failed. more than one local transaction enlisted. xid = machinename/1253684687875

I understand that a local_transaction is opened for each transactional put service used in a flow, which causes problems if you need to have multiple transactional puts in a flow.

I was also of the understanding after reading the MQ Adapter notes that this is the type of service I would need to construct so that I could open, commit, and rollback transactions. Clearly I have gotten something wrong here. Is there enough information here for someone to make a diagnosis? I have named the transaction “putTestMessageGroup” as a constant for each transaction control flow invoked.

Put Adapter Services - Are they using different MQ Connections that points to different queues or same MQ Connection that points to 2 different queues?

In either case, what is the type of MQ Connection that you created - Is it transactional connection or normal mq connection ?