| Author |
Message
|
| fjb_saper |
 Posted: Mon Feb 25, 2008 3:36 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| HubertKleinmanns wrote: |
| fjb_saper wrote: |
Hubert I believe it rather goes this way:
On a physical machine with X CPUs
create a virtual machine with 1 CPU assigned to it
run MQ in that virtual machine.
And not have a Virtual machine with 5 CPUS and (how would you) assign 1 CPU only to MQ...
Enjoy  |
I had a customer, who tried the solution you described above, but then you are not able, to use server bindings between application and QMgr. You have to use MQ client connections instead. The problem with client connections is, that you only have single-phase commit and so you may duplicate message.
My customer could not accept, that messages could be duplicated and so he had to buy further MQ licenses. |
I would have thought that in such a scenario you put a J2EE server up serving your MDBs and MQ requests through stateless session beans to the app farm... ??
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Feb 25, 2008 5:05 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| HubertKleinmanns wrote: |
The problem with client connections is, that you only have single-phase commit and so you may duplicate message.
|
Can you explain why lack of 2 phase commit introduces the risk of duplicate messages? I don't see how single versus 2 phase commit makes a diff in this regard
Or are you thinking of the larger window of oppourtunity for an MQ Client to get a 2009 MQRC on its MQBACK or MQCMIT even for a single phase UOW? Note that a bindings connection shrinks considerably, but does not eliminate 100%, the possability of a 2009 for a MQBACK or MQCMIT.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Feb 25, 2008 11:32 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| fjb_saper wrote: |
| HubertKleinmanns wrote: |
| fjb_saper wrote: |
Hubert I believe it rather goes this way:
On a physical machine with X CPUs
create a virtual machine with 1 CPU assigned to it
run MQ in that virtual machine.
And not have a Virtual machine with 5 CPUS and (how would you) assign 1 CPU only to MQ...
Enjoy |
I had a customer, who tried the solution you described above, but then you are not able, to use server bindings between application and QMgr. You have to use MQ client connections instead. The problem with client connections is, that you only have single-phase commit and so you may duplicate message.
My customer could not accept, that messages could be duplicated and so he had to buy further MQ licenses. |
I would have thought that in such a scenario you put a J2EE server up serving your MDBs and MQ requests through stateless session beans to the app farm... ?? |
I am talking about an application which was developed with "C" (not everthing in the world is written in Java  ). They used simple MQI calls like MQPUT etc. Their system consists out of two servers (AIX with HACMP). On each server one QMgr and a lot (several hundreds) of application instances were running (don't hit me, I am not the application designer  ).
_________________
Regards
Hubert |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Feb 25, 2008 11:59 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| PeterPotkay wrote: |
| HubertKleinmanns wrote: |
The problem with client connections is, that you only have single-phase commit and so you may duplicate message.
|
Can you explain why lack of 2 phase commit introduces the risk of duplicate messages? I don't see how single versus 2 phase commit makes a diff in this regard
Or are you thinking of the larger window of oppourtunity for an MQ Client to get a 2009 MQRC on its MQBACK or MQCMIT even for a single phase UOW? Note that a bindings connection shrinks considerably, but does not eliminate 100%, the possability of a 2009 for a MQBACK or MQCMIT. |
My understanding of two-phase commit is as follows:
- 1st phase: The resource managers are asked by the transaction manager (or resource coordinator), if they were ready to commit. The transaction manager waits for the answers of all resource managers.
- 2nd phase: The transaction manager tells all resource managers, that they now may commit their transactions.
- When the system fails during the 1st phase, all resource managers would rollback the transactions when the come up again.
- When the system fails during the 2nd phase, all resource managers would commit the transactions when the come up again.
- There is a (very) small window during the commit procedure, where the transaction manager cannot decide, if the transaction has to be rolled back or committed. Then you would get an INDOUBT transaction and have to intervene manually.
- Unless a transaction is INDOUBT, the application always knows, if the last message has been accepted by the QMgr or not.
Single-phase commit:
- When an application puts a message with syncpoint control and commits this message, the application receives a reason code MQRC_OK - and everything is fine.
- But when during this commit the connection breaks and the application does not recieve the reason code, it cannot decide, whether the message has been put to the queue or not. Then it depends on the application design, if the application ignores this (missing) reason code or if it puts the message again. Depending on what really happend, you may loose or duplicate messages.
I know, the probability, that such a situation happens is not very high, but my customer told me, that he could not accept any message, which comes twice.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| camauz |
| Posted: Tue Feb 26, 2008 12:17 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
How many resource managers do you have to coordinate?
If your application deals only with messages (no EJBs, no database tables, no distributed transaction processing, etc...), one phase commit is what you need.
Regards
Ch. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue Feb 26, 2008 1:34 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| camauz wrote: |
How many resource managers do you have to coordinate?
If your application deals only with messages (no EJBs, no database tables, no distributed transaction processing, etc...), one phase commit is what you need.
Regards
Ch. |
Could then please tell me, how an application can be sure, that the message has been put to a queue?
_________________
Regards
Hubert |
|
| Back to top |
|
|
| camauz |
| Posted: Tue Feb 26, 2008 2:06 am Post subject: |
|
|
Acolyte
Joined: 20 Aug 2007
Posts: 52
Location: Mojan, Italy
|
| HubertKleinmanns wrote: |
| camauz wrote: |
How many resource managers do you have to coordinate?
If your application deals only with messages (no EJBs, no database tables, no distributed transaction processing, etc...), one phase commit is what you need.
Regards
Ch. |
Could then please tell me, how an application can be sure, that the message has been put to a queue? |
Understand if the SYNCPOINT flag is specified when the application puts the message in the queue.
NO SYNCPOINT: the message is immediately delivered
SYNCPOINT: the message is delivered when the application COMMIT the unit of work.
------------------------------------------------------------------------------------
One phase commit / two phase commit is only related to multiple resource managers scenario.
Example:
1. GET a message from WebSphere MQ
2. INSERT a row into relational database (choose one)
Single phase commit scenario:
- GET message
- INSERT row
- COMMIT database
- COMMIT WebSphere MQ
if the application crashes between COMMIT database and COMMIT WebSphere MQ, you will process the message again due to implicit rollback performed by WebSphere MQ.
Two phase commit scenario:
- START XA global transaction
- GET message
- INSERT row
- commit XA global transaction
if the application crashes while committing the global transaction, the transaction manager will coordinate the resource managers (MQ & database) to rollback the global unit of work.
You can find a lot of information on WebSphere MQ official documentation.
Regards
Ch. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 26, 2008 4:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| fjb_saper wrote: |
| I would have thought that in such a scenario you put a J2EE server up serving your MDBs and MQ requests through stateless session beans to the app farm... ?? |
| HubertKleinmanns wrote: |
I am talking about an application which was developed with "C" (not everthing in the world is written in Java ). They used simple MQI calls like MQPUT etc. Their system consists out of two servers (AIX with HACMP). On each server one QMgr and a lot (several hundreds) of application instances were running (don't hit me, I am not the application designer  . |
Nice try but the above pattern is not limited to J2EE and J2EE appservers.
You could as well implement something like it in a C/C++ world. Yes it would take extensive planning and resources... that would perhaps with the maintenance of the created software go beyond the cost of the extra MQ licenses ???
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 26, 2008 4:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm still not sure I understand the client's rationale in this scenario.
Under what conditions is it useful or even allowable for the queue manager to fail, because it can no longer get enough CPU, while the applications keep running?
I completely understand the desire to save on licensing costs. But the risk here seems to completely outweigh the benefit.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 26, 2008 4:28 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hubert if its just messages and no other updates (i.e. DB inserts) you don't need to concern yourself with 2 phase commits. It buys you nothing.
Based on what you wrote so far I don't even see a need to use basic one phase UOWs. Just MQPUT without syncpoint. If you get a 2009 error code you are then left wondering if the message made it or not. Just like if an MQCMIT returned 2009 if you had issued the put with syncpoint, and just like if the transaction manager was in doubt if you used 2 phase commits.
I would argue that going with a straight MQPUT with no syncpoint might even be better because it eliminates the window between the put that worked and you issuing the MQCMIT. That window is just that much longer where you can lose a connection.
If you want to further minimize (not 100% eliminate) this window you should get a local QM and connect in bindings mode to eliminate the network hop.
You didn't mention MQGETs but if the app you are responsible for is doing those as well you must use syncpoint on thre MQGETs. I just don't think it buys you anything on the MQPUTs. If the message is ready to be put do all the prep work in your app first and then just let that message fly with a non syncpoint MQPUT. Why artificially hold it back with a UOW?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 26, 2008 4:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Without syncpoint, that PUT could succeed on the qmgr side, but appear to fail on the app side.
The app would then, presumably, try to send the message again.
Even on Bindings connections, this is possible.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 26, 2008 4:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Even with syncpoint you get that same possability of not knowing if it worked or not.
MQPUT with syncpoint = MQRC 0
MQCMIT = MQRC 2009
Now what? Did the MQCMIT work and the connection broke after the QM accepted the MQCMIT but before the QM was able to return the status and the message made it? Or did the connection break before the MQCMIT made it and the message is not available?
MQPUT without syncpoint = MQRC 2009
Now what? Did the MQPUT work and the connection broke after the QM accepted the MQPUT but before the QM was able to return the status and the message made it? Or did the connection break before the MQPUT made it and the message is not available?
See how you are asking the same questions either way? If the message is ready to go I say don't use syncpoint on the MQPUT and tighten the window where things can go wrong.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
