This week's book giveaway is in the Agile and Other Processes forum. We're giving away four copies of Darcy DeClute's Scrum Master Certification Guide: The Definitive Resource for Passing the CSM and PSM Exams and have Darcy DeClute on-line! See this thread for details.
Must the request for payment transaction be made in the same thread as the code which received the customer's credit card selection? The requirements do not specify...so I think it is fine to request asynchronously.
I would assume that the payment has to be confirmed via a synchronous process since no business we like to confirm good/service purchase with a customer without payment received confirmation..:-). Starting from customer's credit card submission to payment confirmation has to be in one thread.
I am still unsure if persisting the payment transaction in FBN database should also be done in the same thread as customer's credit card submission. It may be difficult to guarantee the 5 second response time for travel agent.
The required response time for the travel agent is 5 seconds. The credit card transaction authorization could take up to 3 seconds. If all payment processing is done in one thread, and the cc transaction authorization fails, the cc transaction auth will have to be "rolled back". These 2 cc actions could take a total of 6 seconds. Given this, what choice do we have but to make some of the payment processing asynchronous.
Well the "wait for auth" bit is a requirement, ignore it at your peril.
I have not looked in details at the transaction processing API yet, but I suspect that you don't need any kind of rollback once a request has been declined. If you enter the wrong expiry date for your card you should be told there and then so you can have another go. This kind of feedback would constitute a system response within the 5 secs, albeit a negative one.
Thanks for the good advice. By using synchronous transaction payment, we have the following steps:
-send cc transaction authorization -if success - update FBN db - send mileage to Mileage Award - send email (this could be async) -else - update FBN db - send email (this could be async)
So in happy path, we have quite a few transactional activities. Will this meet the 5 second limit? Is the way to handle it to just state which good practices we used to provide the most efficient solution?
I don't think my words should be seen as advice.. just $0.02
I would not worry about the unhappy path too much, I assume that all updates that you make are in a transaction, and if this transaction is rolled back the updates are not made, hence no need to update db. Also I don't recall a requirement to send an email if the transaction fails, only for confirmation ( I would see it as some kind of email receipt )
Hmm, but you're right the timing is tight. Even the best airline sites struggle to give a 5 sec response for transactions.
I wonder if it is possible to give the interaction with the transaction processors to another thread, update the DB, send email etc in the mail thread and then join the transaction thread and wait for confirmation. If positive, just return otherwise rollback?
But I need to give this much more thought.. Is it possible or correct to spawn threads from within an EJB? - would having 600+ concurrent threads be workable? I suspect not, but there may be another way.
There is an issue here, I dont have an answer yet. [ April 09, 2006: Message edited by: Richard Bourner ]
Hello Richard, Thanks for the response. Here are some points.
- The requirements I have say that we send an email if the trans auth fails. I feel this is not a problem since sending emails could be async. - You can't spawn threads from an EJB.
How can the agent's paying be so much faster than customers'? (5 seconds vs. 10 seconds)? They execute the same code. I know the web will be a little slower. Maybe on the agent side, the transactions could be queued. I've seen throughout the posts that we should keep things simple. Any thoughts on queueing? My feeling is that the agent/customer wants to get a synchronous response indicating that the payment has been accepted or has failed.
Thanks for clearing things up about the threads and you're quite right there is a requirement for a failed email to be sent... ( must have missed that one )
I think that the difference between agents and the web users is simply the speed of connection and the quantity of data sent. A web user would need to download the rendered web pages via a 28.8 connection. A 28.8kbit internet connection can only carry 3.6kbytes a second so if the page is 20kbytes that's already 5.5 seconds.
The agents use a COBOL system at present, I suspect that they have some kind of legacy dedicated line in place but is is not specified ( as far as I can see ). I would expect (assume) that agent's networks would use a faster connection in future. ( at least DSL ) I would also expect the application to communicate via RMI or somthing similar so the amount of data transferred would be significantly lower as it has no rendered HTML. One second should cut it for a speedy DSL RMI application ( I hope ).
I'm looking for a way to prioritize the agent's communication but still no certain way to do it..... [ April 09, 2006: Message edited by: Richard Bourner ]
Perhaps. One one hand it could be regarded as part of an atomic transaction, but on the other it is not on the critical path to the client's wallet. No business man would refuse the clients money and booking for this reason.
It is my feeling that it would be a shame for the flight booking, and payment to fail due to a problem with a legacy FF program that could be corrected later.
With async you would:
- Isolate the critical path from problems ( particulary timeouts ) with a legacy FF system. - Speed up transaction processing. - Reduce coupling to a legacy system.
With Sync you would
- Ensure data integrity and transactional closure.
I suppose though that you could isolate the CP from problems even when using sync updates to the FF program. Perhaps the only tangible benefit is speed, but, realistically speaking how long would the update take?
It's a desin choice, my feeling is that async would be more robust in this case, probably
Thank you for the well thoughout comments. I was thinking too about async for the same reasons you mentioned. I read in a different topic of this forum that the mileage award is not applied to the account until the flight actually takes place. This would certainly move it out of the payment transaction. I will research this, but am probably going with the async.
a bit of art, as a gift, that will fit in a stocking