13 Replies Latest reply on May 23, 2007 4:37 PM by timfox

    automatically truncate message table on server startup

    paul_da_programmer

      Due to the constraints of my application, there isn't any need for me to preserve messages in a Queue when the application is bounced. As a matter of fact, persisting them across reboots will have the undesired effect of initiating a flurry of activity when the server comes online when all of the stacked messages all attempt to get processing time at once.

      Is there any configurable way for me to set the Queue to be flushed on startup or shutdown?

      I'm using JBoss 4.0.5 running under JDK 1.5.0_09 under Solaris. I am using Oracle version 9.2 for persistence.



        • 1. Re: automatically truncate message table on server startup
          timfox

          If you don't want to persist messages, then you shouldn't be using persistent messages.

          If you use non persistent messages they won't go into the database in the first place.

          • 2. Re: automatically truncate message table on server startup
            paul_da_programmer

            On the surface that makes sense, but I do want the security (ie the transactionality) that using Oracle offers for my application. In other words, the consumers of the message also update Oracle data, so I want the 2PC transactionality of (ACK of JMS message == updates were performed). If I don't use a transactional DS for persistence, I can't guarantee that.

            Plus, even if I used the Hypersonic (or filesystem) persistence, there still is persistence involved. In other words, when you use JMS, the messages are going to be persisted somewhere across server reboots. Which brings me back to my original question...
            Can you override this default behavior, that is can you have the persistence manager clear its message cache upon startup?

            • 3. Re: automatically truncate message table on server startup
              timfox

               

              "paul_da_programmer" wrote:

              Plus, even if I used the Hypersonic (or filesystem) persistence, there still is persistence involved. In other words, when you use JMS, the messages are going to be persisted somewhere across server reboots. Which brings me back to my original question...
              Can you override this default behavior, that is can you have the persistence manager clear its message cache upon startup?


              That's not correct.

              Non persistent messages don't get persisted, period. Even on hypersonic.

              • 4. Re: automatically truncate message table on server startup
                timfox

                Moved from JBoss MQ forum, since this is a query about JBM.

                BTW please don't crosspost :)

                • 5. Re: automatically truncate message table on server startup
                  paul_da_programmer

                  So would non-persistent messages still preserve the transactional integrity of the JMS transaction?

                  onMsg(...) {
                   //performSomeDBOperation( ) // or any XA transactional operation
                   ...biz throws an uncaught exception which is propagated to the JMS container
                  }
                  

                  Can I assume the DB updates would be automatically rolled back - regardless of whether the message was persisted is a XA resource like a DB? So is JMS itself is an XA transactional resource irrespective of how persistence is handled? If so, that's something I guess I've missed all of these years using JMS.
                  I assumed that JMS being a 'potential' XA resource was only because of it's persistence implementation - I assumed if no persistence is used (or a non-transactional persistence impl like a filesystem) then consistent JMS<->DB transactions couldn't be guaranteed.

                  For so value added here's a good description:
                  http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JMS6.html#wp81843

                  ...from Sun's tutorial...
                  # You can use the setDeliveryMode method of the MessageProducer interface to set the delivery mode for all messages sent by that producer. For example, the following call sets the delivery mode to NON_PERSISTENT for a producer:

                  producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

                  # You can use the long form of the send or the publish method to set the delivery mode for a specific message. The second argument sets the delivery mode. For example, the following send call sets the delivery mode for message to NON_PERSISTENT:

                  producer.send(message, DeliveryMode.NON_PERSISTENT, 3, 10000);

                  The third and fourth arguments set the priority level and expiration time, which are described in the next two subsections.



                  • 6. Re: automatically truncate message table on server startup
                    timfox

                     

                    "paul_da_programmer" wrote:
                    So would non-persistent messages still preserve the transactional integrity of the JMS transaction?


                    The short answer is no.

                    If you want full ACID transactions, you must use persistent messages.

                    Remember the D in ACID stands for durable, and non persistent messages, by definition have no durability.

                    • 7. Re: automatically truncate message table on server startup
                      paul_da_programmer

                      I'm only interested in the ATOMIC ('A' in ACID) aspect of a transaction. What I want to guarantee in using a JMS in a NONPERSISTENT mode is that if the JMS transaction ends abruptly, that all DB work will be back out ATOMICALLY (i.e. all or none)

                      That's why I asked if there is a configurable way for JBoss MQ to be configured to do both
                      1. use persistence, say an XA DB configuration
                      2. but not persist the messages across restarts - i.e. truncate the JMS message table at startup.

                      I know it's a bit of an oddball request, and I know I could just write some "ResetQueue" service that invokes removeAllMessages( ) for the JMS destination and have my MDBs depend on that service... I just was wondering if this was something that existed. It seems that you may want persistent messages for the lifecycle of the execution of your application, while not wanting them to persist ACROSS restarts...

                      • 8. Re: automatically truncate message table on server startup
                        timfox

                         

                        "paul_da_programmer" wrote:
                        I'm only interested in the ATOMIC ('A' in ACID) aspect of a transaction. What I want to guarantee in using a JMS in a NONPERSISTENT mode is that if the JMS transaction ends abruptly, that all DB work will be back out ATOMICALLY (i.e. all or none)


                        If you are using only non persistent messages, then there is nothing to "back out" from the DB, since nothing has been saved to the db.

                        Perhaps I don't follow what you are trying to say...

                        • 9. Re: automatically truncate message table on server startup
                          timfox

                          BTW I gues you meant JBoss Messaging (not JBoss MQ) in your previous post - this is a JBoss Messaging forum.

                          BTW Yes JBoss Messaging implements a fully fledged XA resource implementation.

                          • 10. Re: automatically truncate message table on server startup
                            paul_da_programmer

                             

                            "timfox" wrote:
                            If you are using only non persistent messages, then there is nothing to "back out" from the DB, since nothing has been saved to the db.

                            Perhaps I don't follow what you are trying to say...


                            What I want to back out (or commit atomically) is the XA DB work that my biz functionality has done - using 2PC prepare,ack, commit semantics. If the JMS implementation is an XA compliant one, even without persistence then the answer is yes.

                            I'm thinking this is the sequence of events
                            1. TX manager starts a new XA transaction
                            2. JMS (since its XA) enrolls in the transaction.
                            3. onMsg is invoked, 2 Oracle XA DS are updated, DS1 and DS2. Both are enrolled in the same transaction.
                            4. onMsg returns successfully (so far so good)
                            5. the TX Manager calls prepare on all 3 resources JMS, DS1, DS2
                            6. the TX Mananger receives OK from all three resources
                            7. the TX Manager calls commit on all 3 resources JMS, DS1, DS2
                            8. whoops, DS2 commit fails - and notifies TX Manager
                            9. the TX Manager calls rollback on all 3 resources

                            If JMS if not a XA resource it will not honor the rollback at the last step and would cause the DB updates to never be applied.

                            I hope this explains my motivation...

                            • 11. Re: automatically truncate message table on server startup
                              timfox

                               

                              "paul_da_programmer" wrote:
                              If the JMS implementation is an XA compliant one, even without persistence then the answer is yes.


                              Yes. But this has got absolutely nothing to do with whether JBM persists non persistent messages or not.

                              • 12. Re: automatically truncate message table on server startup
                                paul_da_programmer

                                 

                                "timfox" wrote:
                                "paul_da_programmer" wrote:
                                If the JMS implementation is an XA compliant one, even without persistence then the answer is yes.


                                Yes. But this has got absolutely nothing to do with whether JBM persists non persistent messages or not.


                                I guess that really was my original question, after I refined it with your help :)
                                Q: Is JMS a XA compilant resource even without PERSISTENCE?
                                A: Yes!

                                My misunderstanding came from the assumption that JMS was XA compliant only because of XA compliant persistence.

                                Thanks for your help!

                                • 13. Re: automatically truncate message table on server startup
                                  timfox

                                  Aaah, I think I am beginning to understand your question now :)

                                  You were assuming that JMS implemented being an XAResource by delegating the XA functionality to an underlying XA database?

                                  While you could implement a messaging system this way (and if I remember rightly the Sun tutorial? actually mentions this), you'll find that very few (if any) high quality messaging providers do it this way.

                                  This is because it would tie you to an underlying XA capable database, which is not what all our users would want to use.

                                  So, we implement the XAResource from scratch and don't rely on the existence of any XA capable database.