| Author |
Message
|
| mgarciashiers |
 Posted: Mon Oct 19, 2015 12:32 am Post subject: Recover last put made to a queue from a client app |
 |
|
Newbie
Joined: 27 May 2015
Posts: 3
|
Is there any way to know which is the last message sent to a queue from a client App.
The scenario is as follows:
1.- Client App puts message in the queue
2.- Another Client App is getting the messages.
3.- The Client App that puts crash
4.- Client App continues getting the messages.
5.- When the Client App recovers wants to know which was the last put message in the Queue
thxs for your help |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Oct 19, 2015 12:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The application audit logs should tell you, or if you have a transaction-level monitoring solution that will tell you, but MQ can't tell you other than the last put/get time on a queue.
Your question makes me wonder why, if it is so important for the 'Client App' to know, that it does not record that information somewhere?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mgarciashiers |
| Posted: Mon Oct 19, 2015 1:09 am Post subject: |
|
|
Newbie
Joined: 27 May 2015
Posts: 3
|
Example:
Finantial instruction that cannot be repeated so i want to be sure that the message was in the queue so i dont have to send it again |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 19, 2015 1:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mgarciashiers wrote: |
Example:
Finantial instruction that cannot be repeated so i want to be sure that the message was in the queue so i dont have to send it again |
If the message cannot be repeated then your putting application needs to maintain an audit of what it has, or has not, done. This is an application problem, not an MQ problem.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mgarciashiers |
| Posted: Mon Oct 19, 2015 1:42 am Post subject: |
|
|
Newbie
Joined: 27 May 2015
Posts: 3
|
Sure, but i´ve and scenario in which i dont know how to handdle, any help will be appreciated.
scenario 1
1.- Client App get message from database
2.- Client App Puts mesagge in a Queue
3.- Client App Commit the put in database
4.- Client App Commit to MqServer
Between 3 and 4 Client App crash for database msg is sent but is not
Scenerio 2
1.- Client App get message from database
2.- Client App Puts mesagge in a Queue
3.- Client App Commit to MqServer
4.- Client App Commit the put in database
Between 2 and 4 Client App crash the message is sent but for database is not |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Oct 19, 2015 2:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
This is where XA comes into its own (provided this is possible)
The neverything is done under the same UOW and the DB commit is not done until the MQ Commis is done and vice versa.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 19, 2015 2:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Scenario 1 and Scenario 2: The read from and update of the database, and put/get of the message should be wrapped into the same unit of work, which means should either of the operations fail a roll-back will occur, i.e. the database will not be updated and the message will never have been put.
If your Client App is connecting to the queue manager in bindings mode (cross-memory), or client mode (network), you need to set up the queue manager to participate in a distributed Unit of Work, and of course the applications need to be coded appropriately.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 19, 2015 4:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| mgarciashiers wrote: |
Sure, but i´ve and scenario in which i dont know how to handdle, any help will be appreciated.
scenario 1
1.- Client App get message from database
2.- Client App Puts mesagge in a Queue
3.- Client App Commit the put in database
4.- Client App Commit to MqServer
Between 3 and 4 Client App crash for database msg is sent but is not
Scenerio 2
1.- Client App get message from database
2.- Client App Puts mesagge in a Queue
3.- Client App Commit to MqServer
4.- Client App Commit the put in database
Between 2 and 4 Client App crash the message is sent but for database is not |
As said the solution is to put everything into the same unit of work.
In the meantime...
There is an application consuming these messages... and there should be some kind of ability to verify...
a) what is the last message marked as processed in the DB
b) what is the consumer reporting as last message processed
And go from there. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
