Creating a QueueReceiver after sending message to the QueueSender

Question

          Hi,
          I'm implementing a blocking system, sending messages to a JMS Queue.
          In a servlet, in the init method, I'm creating the QueueSender object.
          When calling the servlet, in the service method, if I need to create a new
          message to let users know
          that one primary key is blocked, I create a message with a:
               msg.setStringProperty("MyTablePrimaryKey", "PKValue");
          Then, I send it.
          If other clients want to update that record, he creates in the servlet's service
          a QueueBrowser like this:
          QueueBrowser receptor=qsession.createBrowser (myQueue, strFilter);
          where strFilter is "MyPrimaryKey IS NOT NULL".
          If the enumeration my QueueBrowser returns hasMoreElements(), the record is
          blocked.
          To unblock a record, I fetch the message from QueueBrowser with the with Enumeration.nextElement,
          and I set:
          message.setJMSExpiration(1);
          so the message is automatically deleted from the queue.
          I tried to use QueueReceiver to implement it, but as I don't know the filter's
          name in the init method of my servlet,
          it's not possible to read messages if the QueueReceiver is created after having
          sent those messages.
          Is my implementation correct? Is the behaviour of QueueReceiver logical?
          Of course, I'm thinking of doing all these things in EJBs to use transactions
          with JTA and JMS. Can be any problem
          with it?
          Sorry for the long question, but I've started discovering JMS a few hours
          ago, and it looks so interesting... :-)
          Best Regards,
          Ignacio
          

Answer 1

          Ignacio Sanchez wrote:
          > Tom Barnes <[email protected]> wrote:
          >
          >>
          >>Ignacio Sanchez wrote:
          >>
          >>>Hi,
          >>>
          >>> I'm implementing a blocking system, sending messages to a JMS Queue.
          >>>
          >>> In a servlet, in the init method, I'm creating the QueueSender
          >>
          >>object.
          >>
          >>> When calling the servlet, in the service method, if I need to create
          >>
          >>a new
          >>
          >>>message to let users know
          >>>that one primary key is blocked, I create a message with a:
          >>>     msg.setStringProperty("MyTablePrimaryKey", "PKValue");
          >>> Then, I send it.
          >>>
          >>> If other clients want to update that record, he creates in the
          >>
          >>servlet's service
          >>
          >>>a QueueBrowser like this:
          >>> QueueBrowser receptor=qsession.createBrowser (myQueue, strFilter);
          >>> where strFilter is "MyPrimaryKey IS NOT NULL".
          >>> If the enumeration my QueueBrowser returns hasMoreElements(), the
          >>
          >>record is
          >>
          >>>blocked.
          >>
          >>
          >>How? The QueueBrowser supplies a snap-shot of the queue, it doesn't
          >>prevent other receivers and queue-browsers from seeing the message.
          >>
          >
          >
          > That's exactly what I want. I want concurrent queue-browsers to see the same message.
          >
          >
          >>>
          >>> To unblock a record, I fetch the message from QueueBrowser with
          >>
          >>the with Enumeration.nextElement,
          >>
          >>>and I set:
          >>
          >>> message.setJMSExpiration(1);
          >>> so the message is automatically deleted from the queue.
          >>
          >>
          >>This will have no effect. Expiration can only be set when the message
          >>is sent, and only via the producer API not the message API. The message
          >>API setter is not intended for application use (see the
          >>javax.jms.Message javadoc). To delete the message you can
          >>create a QueueReceiver with a selector based on the message's
          >>message-id, then receive and acknowledge the message.
          >>
          >
          >
          > But it works!! I've tested once and again and it works fine for me. Shouldn't
          > it???
          >
          Gah!! This behavior is not supported. Do not depend on it to
          be there in future releases or SPs. Any changes to an already
          sent message by a client should propagate to the copy that
          is on the server.
          In fact, I think this may have already been fixed. Can you
          tell me which release and SP you are using?
          >>>
          >>> I tried to use QueueReceiver to implement it, but as I don't know
          >>
          >>the filter's
          >>
          >>>name in the init method of my servlet,
          >>> it's not possible to read messages if the QueueReceiver is created
          >>
          >>after having
          >>
          >>>sent those messages.
          >>
          >>I don't understand. If you can create the QueueBrowser when you
          >>need it, why can't you just create a QueueReceiver with a new selector?
          >
          > If I create a new QueueReceiver after having sent the message using a QueueSender,
          > the
          > receiver cannot read the messages already posted, even in selector is OK. But
          > it works with
          > a QueueBrowser ¿¿??¿¿
          If a QueueBrowser can see the message so should a QueueReceiver. They
          both use the same filter/selector mechanism. It is surprising
          that one worked and the other didn't. Or are you referring to
          the normal behavior that only one QueueReceiver can "see" the message
          at a time? And that once a QueueReceiver has a message the
          QueueBrowser will not "see" it?
          > That's why I'm using QueueBrowser and not QueueReceiver.
          >
          >
          >>>
          >>> Is my implementation correct? Is the behaviour of QueueReceiver
          >>
          >>logical?
          >>
          >>>
          >>> Of course, I'm thinking of doing all these things in EJBs to use
          >>
          >>transactions
          >>
          >>>with JTA and JMS. Can be any problem
          >>> with it?
          >>>
          >>> Sorry for the long question, but I've started discovering JMS a
          >>
          >>few hours
          >>
          >>>ago, and it looks so interesting... :-)
          >>>
          >>> Best Regards,
          >>> Ignacio
          >>
          >