| Author |
Message
|
| meetgaurav |
 Posted: Wed Oct 29, 2008 7:00 am Post subject: MQ and MDB problem !!!!!! HELP NEEDED |
 |
|
Voyager
Joined: 08 Sep 2008
Posts: 94
|
HI
My MDB is running in OC4J. Say for EX: it has 10 instances. The MDB is picking the Message from Websphere MQ Asynchronously. The problem is “ My application is online reservation and the user can reserve the ticket and then immediately cancel that ticket. Reservation is one message and cancellation is another message. While the MDB is Asynchronously picking the message from the MQ. In case if the MDB picks the cancellation message before reservation message, problem will occur” How to handle this situation"
Any Possibility of using message selector in OC4J deployment descriptor
 |
|
| Back to top |
|
 |
| atheek |
| Posted: Wed Oct 29, 2008 11:56 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
The simplest way is to make your mdb single thread ie run only one instance. But what you end up is an application with message affinity that is not scalable and hence highly NOT recommended.
You can use a delayed processing approach for treating cases where cancellation messages arrive before reservation ones. In this approach when a cancellation message is processed and its known that there is no corresponding reservation message in the db, don't discard the message. Rollback the message to the source queue and process it after a configured retrial interval.There is a high possibility that the original reservation message will get updated within this period. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 29, 2008 6:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| atheek wrote: |
The simplest way is to make your mdb single thread ie run only one instance. But what you end up is an application with message affinity that is not scalable and hence highly NOT recommended.
You can use a delayed processing approach for treating cases where cancellation messages arrive before reservation ones. In this approach when a cancellation message is processed and its known that there is no corresponding reservation message in the db, don't discard the message. Rollback the message to the source queue and process it after a configured retrial interval.There is a high possibility that the original reservation message will get updated within this period. |
Nice concept Atheek but not that easily workable as the next instance of the MDB will pick up the message as it gets available.
Better stick it into the DB with timestamp and status and key.
So when you get an update for the key check the timestamp on the message and if it is prior to the timestamp on the record write directly to history and do not write to live data as the record you're about to process is obsolete...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| atheek |
| Posted: Wed Oct 29, 2008 7:16 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
OK..I had in my mind what meetgaurav has mentioned in his other thread
http://www.mqseries.net/phpBB2/viewtopic.php?t=46029
and thought that his mdb is actually polling a third party queue.
BEA Weblogic's JMS implementation has a smart feature called Redelivery Interval and Redelivery Count. Once a message is rolled back, the jms provider won't redelievr the message again back to the application until the redelivery interval has expired. The redelivery interval can be set at the JMS Destination or Connection Factory level or within the application. I thought if his third party jms provider do support this feature then this could have been used.
Not sure if these are part of standard jms spec or BEA's custom extension. Wonder whether this is worth enough to be put in a wish list for MQ JMS. |
|
| Back to top |
|
|
| meetgaurav |
| Posted: Thu Nov 20, 2008 9:17 pm Post subject: |
|
|
Voyager
Joined: 08 Sep 2008
Posts: 94
|
| Quote: |
You can use a delayed processing approach for treating cases where cancellation messages arrive before reservation ones. In this approach when a cancellation message is processed and its known that there is no corresponding reservation message in the db, don't discard the message. Rollback the message to the source queue and process it after a configured retrial interval.There is a high possibility that the original reservation message will get updated within this period.
|
Actually Atheek this is a good idea, and we strarted thinking about this but again we come with a different problem.
In case of cancellation we will rollback the message and put a sleep in catch block after certain time the cancellation message will be processed. This is fine
But here another problem is am booking a ticket of 3 members and then changing it to 5 then after some time they were changing it to 4 tickets. Here 3 tickets will be booked after some time 4 tickets message may come and then finally the MDB may receive 5 tickets message. And finally this will become invalid transaction. Client booked 4 at last but the MDB will send the second message 5 tickets at the last.
Please advice |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 21, 2008 1:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| meetgaurav wrote: |
| Quote: |
You can use a delayed processing approach for treating cases where cancellation messages arrive before reservation ones. In this approach when a cancellation message is processed and its known that there is no corresponding reservation message in the db, don't discard the message. Rollback the message to the source queue and process it after a configured retrial interval.There is a high possibility that the original reservation message will get updated within this period.
|
Actually Atheek this is a good idea, and we strarted thinking about this but again we come with a different problem.
In case of cancellation we will rollback the message and put a sleep in catch block after certain time the cancellation message will be processed. This is fine
But here another problem is am booking a ticket of 3 members and then changing it to 5 then after some time they were changing it to 4 tickets. Here 3 tickets will be booked after some time 4 tickets message may come and then finally the MDB may receive 5 tickets message. And finally this will become invalid transaction. Client booked 4 at last but the MDB will send the second message 5 tickets at the last.
Please advice |
Same problem with message affinity...
You need to have your transactions timestamped and have the timestamp in the DB. Your transactions cannot be dependent on data of previous transactions... i.e. after applying 1.5 regardless of whether you applied 1.4 the state needs to reflect 1.5.
So when you receive a transaction you check against datetimestamp and if prior to the last in the db you write to history without processing.
Note you cannot do this with financial transactions.
Have fun:
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| meetgaurav |
| Posted: Fri Nov 21, 2008 3:08 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008
Posts: 94
|
[quote]Note you cannot do this with financial transactions. [/quote]
May I know the reason for this... |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Nov 21, 2008 3:46 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
Account Balance is 100$. You do a credit for 50$ and then a debit for 125$ . It will work occur only if the transactions are processed in the sequence in which they occur. If the debit message came before credit, then it will fail with an insufficient funds error.
Messages exchanged in financial transactions are often deltas which contain only details of what change is intended by that message.
In messaging, you can have two types : deltas and snapshots.
Deltas contains only changes to an object, while snapshots contain the full object including the changes. As a result any snapshot message will give the full representation of the object at that point of time.
In your example you are using snapshots. When the reservation changed, you are stating that the as per the latest status ticket is booked for 4 person. This information is contained in your new message.
If you were using delta model, the new message will contain information to add one more user. This needs to be read in with the previous transaction that the ticket was booked already for 3 users. . Delta messages often will be lesser in size as only it contains fields that changed. However, it introduce message affinity which should be avoided wherever possible. |
|
| Back to top |
|
|
| meetgaurav |
| Posted: Fri Nov 21, 2008 4:08 am Post subject: |
|
|
Voyager
Joined: 08 Sep 2008
Posts: 94
|
Atheek / FJB
Then wat will be the solution for this problem. Please assist me |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Nov 21, 2008 4:18 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| When the 4 member message come, will it contain the details of all 4 members? I assumed it was and hence thought you are using snapshots. Does that message and the database table schema has a field [ either a sequence number or a timestamp] for transaction ordering. If Yes is your answer to both of these questions you can implement the solution advised by FJ. |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Nov 21, 2008 4:31 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| meetgaurav wrote: |
| ...and put a sleep in catch block after certain time the cancellation message will be processed |
Don't do this. Go for delayed processing approach only if the jms provider support redelivery delay. If you handle it in your code at the mdb it could seriously impact the throughput. |
|
| Back to top |
|
|
|
|
