[Phpwebsite-developers] Transaction queues / managers (xmlrpc, et al)

[W.D.Sumilang <wa...@on...>]

(RE: xml-rpc, thought it was relevant. Found this on another list - WD)

    I've been lurking for a while, just thought i'd throw in something
I've learnt from experience to think about.
    If you are looking at using xmlrpc or other API to interface with
systems then you should really look at transaction queues / managers.
    For instance, say you need to hit three different systems - pull
data from the first system,  update data in the second system with the
data you just grabbed and fire an unrelated event to the third system.
Sounds easy enough right? What happens if each of these systems take
15 seconds to respond? You now have the user waiting 45 seconds for a
response - they'll probably hit refresh and kick off a second transaction,
corrupting your data.
    You can improve the response times by parallelizing the requests,
bundle the first two requests into a transaction and rund the third request
concurrently - the response time is now 30 seconds.
    Now suppose that the user won't be looking at the results, maybe
they just wanted to synchronise the systems and get back to using the
site. The response isn't relevent to the task the user is performing.
A further optimisation would be a fire and forget system. Example, put
the request on a queue and get an immediate response confirming the request.
When the transaction is complete, a callback could be used to return
success or failure, and in the event of failure a rollback could be attempted.
The work is still done and the user can go about their business without
long waits.
    Of course the implementation of something like this is where the
fun starts, it really stretches PHP but is possible I think.

__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com