Richard Bourner

Hi,

i remember from another post that a pre-condition is not necessarily an invariant.

Hope that helps,

Richard.

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

Hi Saha,

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 ]

Hi,

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 ]

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.

I smell trouble for async payment. $0.02

I guess it must be in the same thread see the use case specification: Pay for itinerary - Basic Flow

"System sends payment transaction to TM and waits for auth..."

Also try googling JUDE it's lightweight and easy to use.

Hi thanks for the reply, I have read the assignment a couple of times now and it is coming into focus. At the moment I'm wondering how the hell the business analysis came up with "Equipment" in the domain model. No wonder he's no longer with the company.

Is is fair to assume that the domain model is concrete and not changeable or should we try to improve on it?

As far as I can it seems that there is a requirement for the agents to have faster access than the web users, but if you read on the "hard requirement" is that access time never exceeds 5 secs end to end and that web access never exceeds 10 secs.

I would think that one could assume that agents connections are fast and therefore would have no download latency, say, 1 sec worst case, and that communication with transaction processing backend is 3 secs worst case ( as per SLA ) that gives you two secs for processing each request. Using exactly the same backend would give the web users 6 seconds for downloading the rendered html on a 28.8 which sounds reasonable to me.

I expect that there are no need for prioritising agent initiated processing.

Hi,

I've just passed SCEA I with 85% ( A big big thak-you to all who post on this site ) and am about to start part II. Any advice on where to begin and what is expected would be very much appreciated.


Rick.