Putting JMS Queues into a database

[Mark Herschberg]

I want to add a (JMS) TemporaryQueue to a database (Oracle 9i). Unfortunately, it's not serializeable. Is there any way to store it in the DB (so that it is accessible using EJBs)?
--Mark

[Peter den Haan]

Mark, it's not clear to me what you want to achieve. Do you want your queue to be backed by the Oracle database? That is usually fairly straightforward, but depends on your JMS implementation. Or do you want to serialize your queue as a whole, contents and all? That might never work unless your JMS implementation was designed with this in mind (and why would you want to do that?).
- Peter
[ March 05, 2003: Message edited by: Peter den Haan ]

[Mark Herschberg]

I have people who log into my system and provide a temporary queue (used just for the login session), by which the server should send JMS messages to the user.
I need to keep track of which queue belongs to which user. Because this is an EJB system, it seems the right way to do this is with entity beans, which would be backed by the database.
Make sense?
--Mark

[Paulo Salgado]

I think you can't specify a name when creating a TemporaryQueue, which leads me to believe you can get a different name when the same user establishes a new QueueConnection. Not sure on this one, but seemed logical to me. If your idea is to keep track if the user is always using the same queue and the above is true, what you want may not work.
Paulo

[Mark Herschberg]

Originally posted by Paulo Salgado:
I think you can't specify a name when creating a TemporaryQueue, which leads me to believe you can get a different name when the same user establishes a new QueueConnection. Not sure on this one, but seemed logical to me. If your idea is to keep track if the user is always using the same queue and the above is true, what you want may not work.

You are correct, but that's fine. If I always wanted the same name, I couldn't use a TemporaryQueue; but then, I could write off the name in a property file.

The point here is that the user logs in, and during the login session, I always need the same Temporary Queue. Once the user logs out, I throw away the TemporaryQueue, but that's fine, since a new one will be created next time.
I just need a place to store a reference to the TemporaryQueue on the server. Since this is an EJB application, entity beans seem like the right way to do it, and that puts it in a database.
--Mark

[Paulo Salgado]

Mark,
if the producer always create a Message with a reference to the TemporaryQueue in the JMSReplyTo header, you will always have this info when processing a message from that specific producer and will be able to respond, without persisting a reference to the producer's TemporaryQueue anywhere.
That would be an option to avoid the persistence of the producers' TemporaryQueue's, which, by the way, I don't know how can be done.
Paulo

[Mark Herschberg]

Originally posted by Paulo Salgado:
Mark,
if the producer always create a Message with a reference to the TemporaryQueue in the JMSReplyTo header, you will always have this info when processing a message from that specific producer and will be able to respond, without persisting a reference to the producer's TemporaryQueue anywhere.

Yes that is certinaly true, but is only useful when all server-sent messages are responses. In my application, the server will be asynchronously sending messages to the client--messages the client wasn't necessarily requesting at that moment (e.g. let me know when this value changes on the server).

--Mark

[Paulo Salgado]

So, you need a reference to each client's TemporaryQueue so your server app sends each one of them updates when those happen.
I'm wondering here if it would be possible to programatically add object references to a naming context using JNDI. This could do what you want, but I don't know if it is feasible.
In the meanwhile, another thought: Pub/Sub may be an option. You can have your clients subscribing to a permanent Topic and use selectors to make the clients receive only messages concerning them.
Paulo
[ March 05, 2003: Message edited by: Paulo Salgado ]

[Mark Herschberg]

Originally posted by Paulo Salgado:
I'm wondering here if it would be possible to programatically add object references to a naming context using JNDI. This could do what you want, but I don't know if it is feasible.

Hmm, that's a possibility (we were also thinking of just keeping a singleton HashMap, although it's not a great design).

Originally posted by Paulo Salgado:
In the meanwhile, another thought: Pub/Sub may be an option. You can have your clients subscribing to a permanent Topic and use selectors to make the clients receive only messages concerning them.

Unfortunately, that's not very fesible. We're looking at having 100 users logged in at once, and around 10 messages sent to all of them, per second (global updates). Then we have those personal messages, if we send 1 a second, we send 100 additional messages (personal messages). If we send 1 per second (of personal messages) to all users, we'll be sending 10,000 additional messages (100 users x 100 personal messages), which brings the JMS load up by an order of magnitude.
BTW, the original motivation for this comes from my issue here.
--Mark

[Paulo Salgado]

Unfortunately, that's not very fesible. We're looking at having 100 users logged in at once, and around 10 messages sent to all of them, per second (global updates). Then
we have those personal messages, if we send 1 a second, we send 100 additional messages (personal messages). If we send 1 per second (of personal messages) to all
users, we'll be sending 10,000 additional messages (100 users x 100 personal messages), which brings the JMS load up by an order of magnitude.

Well, then I may have misunderstood how an implementation of the Pub/Sub model works. Here's what I have in mind (remember I mentioned the use of message selectors):
Whenever a client logs in, it subscribe to the Topic using the selector, say, USERID='<its_own_id>' OR USERID='ALL'.
When your global update EJB creates a message for everybody, it adds the USERID property to the message with value 'ALL'.
When your personal update EJB creates a message for a specific userid, it adds the USERID property to the with the userid it is currently working on.
The key concept I had in mind is that the messages would be delivered only to those clients whose selectors matched the properties in the message, therefore it wouldn't be a 10,000 increase in the number of messages, but each client would receive only what it needs.
If you had only 'personal' updates I'd to use a Queue instead of a Topic, but with the 'global' updates, the Topic seems to be more adequate.
In your statement quoted above did you mean that even with selectors, all the clients would get all the messages ? I wasn't expecting the implementation to work like that.
Paulo

[Dana Hanna]

I agree with Paulo in respect to the Pub/Sub usage. I do see your concern in network traffic to all users though. The spec states that "Messages filtered out by a subscriber's message selector will never be delivered to the subscriber. From the subscriber's perspective, they do not exist. "
However, this doesn't address whether they are detected as filtered out by the subscriber implementation, or the publisher implementation. If they are filtered by the subscriber, there is serious network overhead. Perhaps further research into your JMS implementation would be most beneficial.
What JMS implementation are you using? Do they provide source? Can you de-compile and see how this is done?