Java and Oracle Advanced Queues

[DaWickedRebel]

Hi

Was wondering if anyone has had any experience and/or success using Oracle Advanced Queues in a 3-tier architecture.

I have a system where currently client machines make a DB Connection, register to an Oracle queue, and dequeue locally.

What I'd like to do is create a Data Access Layer where we can pool connections from a central location and not have our clients talking to the DB directly. Clients would ask the DAL for information, and the DAL would return that information.

The problem is our clients need to receive 'Live' updates whenever certain events occur (we currently 'poll' the queue every 2 seconds, updates are frequent).

I'd appreciate any advice on how to manage the consumers from the DAL. Do I need to have a queue of my own in the DAL where I manage who is connected? Is there a simpler way to handle consumers and to push messages to the clients?

I hope my question is somewhat clear. Thanks for any advice you might have.

Rich

 

[stevexff]

Are all the clients polling the same queue? If so, is it a race to see who gets the next hot item, or is it a broadcast type message that they all need to see?

Do Oracle Advanced Queues have any event-driven capabilities (i.e. rather than polling them every 2 seconds to see if there's any news, can't you get them to trigger/post/callback/whatever when something arrives)?

 

[DaWickedRebel]

Hi Steve, and thanks for answering.

Yes, all our clients register to the same queue, and it is a broadcast system where everyone registered needs to dequeue the newest messages before they are cleared from the queue. A single client will read a unique message only once.

As for callback functionality, I know I've read that there is support for asynchronous notification for OCI clients, though I'm not sure if an outside Java application will be able to utilize it. In truth, I'm no Oracle expert. I suppose we all have to wear many hats in our duties, so I should probably read more on Oracle and speak to our DB guy here.

In the meantime, perhaps I could plan for both possibilities: one where we can have the queue notify the client of new messages, and one similiar to how we operate now, where we poll the queue at a regular interval.

 

[stevexff]

In that case there are two issues:

An unknown number of clients all poll the queue every 2 seconds to see if there is anything to do. This scheme breaks down if you have a lot of clients, as you expend a lot of system resources polling the queue even when there is nothing to do.

But if you intercept the message using an event driven scheme, you still have to manage the broadcast to all the clients yourself, which kind of defeats the object of using the broadcast queue in the first place. This is even worse if the messages are persistent (have guaranteed delivery) as you have to worry about recovery as well. Suppose one of the clients doesn't connect for a couple of days? Will they need to see their backlogged messages?

 

[DaWickedRebel]

No no..no persistant messages. To put it briefly, a client will load everything he needs from the database into memory when he opens the app (it's a ton on data) and then we use the queue to broadcast changes to any of the objects rather than deal with the overhead of querying the database which slows our app down to a crawl. There are a variety of different apps manipulating our data so the queue gives us a central location to handle broadcasting changes. But anytime a client signs off, he will simply load up 'fresh' the next time he opens the app.

You are definitely right about wasting resources though, as for instance late at night there are very few changes happening though the queue is still polled every two seconds.