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.

Rgds,

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.

HTH,
RMG

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.

HTH,
RMG

Hi RMG,
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.

Senthil

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…

Senthil

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…

-Senthil

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.

Regards
Durga

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.

regards
Shyam

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.

startTrans
MAIN
TRY
updateDb1
insertDb1
updateDb2
mqPut1
commitTrans
CATCH
getLastError
rollbackTrans

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 :

startTransaction
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”

StartTransaction
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 :

" com.wm.pkg.art.error.DetailedServiceException: [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

regards
Shyam

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 ?

I should clarify, yes:

1. They are two transactional connections to separate queues on the same queue manager.

The Adapter documentation is weird - on p20 it says for implicit transactions it can only deal with one local_transaction and to deal with more than one you need to control your own transactionality. In the section before the index it says explicit transaction contexts can have only one local_transaction. Read together, it would appear that multiple transactional puts are not possible.

Using non-transactional connections I get the results I expect, ie the messages get put independently of any transactional constructs in the flow.

Chris,

In page 193, it is clearly mentioned

[/SIZE][/FONT][/SIZE]

I very much appreciate your words, Senthil.

I swapped out the put1 and put2 services with non transactional versions of the same and the messages persist to the queue regardless of whether I rollback or commit. I even changed the commit to a rollback to make sure I would encounter a rollback without any branching with the same result.

One interesting thing which I also encountered is that when stepping through in the developer, transactional messages persist to the queue always.

I find the documentation of the product to be frustrating. It is written in a style that makes it quite easy to read and all the information is there, but somehow it is difficult to find with any precision exactly the information I need.

Chris,
Yes, If you step through the code, transactional messages will persist in the queue… It is known fact… You will have to run the service to check the transactionality…

Can you try this… Remove the begin/commit/rollback tran from your code… Create non transactional connection that points to 2 queues… In the try, you will have 2 put adapter services called (not a wrapper service which in turn calls adapter service)…

Service level commit/rollback should happen i believe. Check with some sample messages, where one put adapter returns success and one returns failure.

Regards,
Senthil