File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JDBC and the fly likes Putting JMS Queues into a database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Putting JMS Queues into a database" Watch "Putting JMS Queues into a database" New topic
Author

Putting JMS Queues into a database

Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
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
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
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
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
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
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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
Ranch Hand

Joined: Jan 18, 2002
Posts: 98
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
Ranch Hand

Joined: Feb 28, 2003
Posts: 227
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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Putting JMS Queues into a database