Comments on: Queuing and Decoupling for Performance… http://www.oracle-base.com/blog/2009/10/14/queuing-and-decoupling-for-performance/ Oracle related rants (and lots of off-topic stuff)... Tue, 16 Mar 2010 10:42:42 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Tim... http://www.oracle-base.com/blog/2009/10/14/queuing-and-decoupling-for-performance/comment-page-1/#comment-112419 Tim... Wed, 14 Oct 2009 19:43:38 +0000 http://www.oracle-base.com/blog/?p=1104#comment-112419 Hi. Of course, you have to apply some sense to it. I purposely said "business function" because business functions usually involve transactions bigger than a single insert. :) Cheers Tim... Hi.

Of course, you have to apply some sense to it. I purposely said “business function” because business functions usually involve transactions bigger than a single insert. :)

Cheers

Tim…

]]> By: Nigel Thomas http://www.oracle-base.com/blog/2009/10/14/queuing-and-decoupling-for-performance/comment-page-1/#comment-112417 Nigel Thomas Wed, 14 Oct 2009 18:59:25 +0000 http://www.oracle-base.com/blog/?p=1104#comment-112417 I agree but with one reservation - don't queue a unit of work that costs less than the cost of the queue and de-queue. I would almost call that an anti-pattern. Especially so when the work is dequeued by polling (which costs even when there is no work to do): - client stores a record in a table identifying work to do - server polls the table looking for unprocessed items... Get the polling frequency wrong (or the indexing) and you can sink the entire app (I once flew all the way to Inverness to discover within 20 minutes that a too-frequent poll of background work was the reason for a housing benefit system disappearing up its own fundament). I've seen the same with the use of message beans and AQ. The AQ interface looks interrupt driven but there is polling under the counter... Regards Nigel I agree but with one reservation – don’t queue a unit of work that costs less than the cost of the queue and de-queue. I would almost call that an anti-pattern. Especially so when the work is dequeued by polling (which costs even when there is no work to do):

- client stores a record in a table identifying work to do
- server polls the table looking for unprocessed items…

Get the polling frequency wrong (or the indexing) and you can sink the entire app (I once flew all the way to Inverness to discover within 20 minutes that a too-frequent poll of background work was the reason for a housing benefit system disappearing up its own fundament).

I’ve seen the same with the use of message beans and AQ. The AQ interface looks interrupt driven but there is polling under the counter…

Regards Nigel

]]>