Non-Transacted sessions - Weblogic

This is a discussion on Non-Transacted sessions - Weblogic ; Hi I wonder if someone could give me a clear and definitive answer as to what exactly is meant by a non-transacted session, AND how does this differ from a transacted session. I've had a poke about Sun's JMS Spec ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Non-Transacted sessions

  1. Non-Transacted sessions


    Hi I wonder if someone could give me a clear and definitive answer as to what exactly
    is meant by a non-transacted session, AND how does this differ from a transacted
    session.

    I've had a poke about Sun's JMS Spec and still can get a handle on the difference

    As far as I can see it, if I develop a small Java application to send JMS Messages
    to a queue, I can create a connection to the box that hosts the WLS, then grab
    the initial context, look up the queue name via the connection factory, then go
    on to create a session to send the messages to the queue.

    Could some one tell me what the pro's and cons of using a Transacted or Non-Transacted
    session would be in this type of scenario?

    Also are the message acknowledgements still used in a transacted session?





  2. Re: Non-Transacted sessions


    "Barry Myles" wrote:
    >
    >Hi I wonder if someone could give me a clear and definitive answer as
    >to what exactly
    >is meant by a non-transacted session, AND how does this differ from a
    >transacted
    >session.
    >
    >I've had a poke about Sun's JMS Spec and still can get a handle on the
    >difference
    >
    >As far as I can see it, if I develop a small Java application to send
    >JMS Messages
    >to a queue, I can create a connection to the box that hosts the WLS,
    >then grab
    >the initial context, look up the queue name via the connection factory,
    >then go
    >on to create a session to send the messages to the queue.
    >
    >Could some one tell me what the pro's and cons of using a Transacted
    >or Non-Transacted
    >session would be in this type of scenario?
    >
    >Also are the message acknowledgements still used in a transacted session?
    >
    >
    >
    >


    You use the transacted session to send a bunch of messages in a single transaction
    . Till you issue commit, the messages won't be delivered to the receivers. If
    you rollback, nothing is published on to the server.

    In the case of non-transacted session, as soon as you publish , the message goes
    to the JMS server which in turn goes to the receiver(s).

    If you use transacted session for receive, the messages are acknowledged as soon
    as you call commit

    I found Java Message Service by Richard Monson-Haefel a very valuable reference


    Murali



  3. Re: Non-Transacted sessions


    "L Muralidharan" wrote:
    >
    >"Barry Myles" wrote:
    >>
    >>Hi I wonder if someone could give me a clear and definitive answer as
    >>to what exactly
    >>is meant by a non-transacted session, AND how does this differ from

    >a
    >>transacted
    >>session.
    >>
    >>I've had a poke about Sun's JMS Spec and still can get a handle on the
    >>difference
    >>
    >>As far as I can see it, if I develop a small Java application to send
    >>JMS Messages
    >>to a queue, I can create a connection to the box that hosts the WLS,
    >>then grab
    >>the initial context, look up the queue name via the connection factory,
    >>then go
    >>on to create a session to send the messages to the queue.
    >>
    >>Could some one tell me what the pro's and cons of using a Transacted
    >>or Non-Transacted
    >>session would be in this type of scenario?
    >>
    >>Also are the message acknowledgements still used in a transacted session?
    >>
    >>
    >>
    >>

    >
    >You use the transacted session to send a bunch of messages in a single
    >transaction
    > Till you issue commit, the messages won't be delivered to the receivers.
    >If
    >you rollback, nothing is published on to the server.
    >
    >In the case of non-transacted session, as soon as you publish , the message
    >goes
    >to the JMS server which in turn goes to the receiver(s).
    >
    >If you use transacted session for receive, the messages are acknowledged
    >as soon
    >as you call commit
    >
    >I found Java Message Service by Richard Monson-Haefel a very valuable
    >reference
    >
    >
    >Murali
    >
    >



    Thanks for the reply very helpful, just so I understand 100%

    >In the case of non-transacted session, as soon as you publish , the message
    >goes
    >to the JMS server which in turn goes to the receiver(s).


    In a non transacted session then, the action of sending the message to the receiver
    is enough to publish the message on the server, whereas in a transacted session
    we would send the message (or bunch of messages) to the server, then issue a commit()
    on that session. This would then publish the message on the server.

    If that's true then I take it there is no way of rolling back a non transacted
    session?

    Also for Transacted and Non-Transacted sessions at what stage are the messages
    acknowledged

    I'd guess for a Non-Transacted session - after the message is delivered

    and for a Transacted session - after the commit occurs

    am I correct?


  4. Re: Non-Transacted sessions



    Barry Myles wrote:

    >
    > In a non transacted session then, the action of sending the message to the receiver
    > is enough to publish the message on the server, whereas in a transacted session
    > we would send the message (or bunch of messages) to the server, then issue a commit()
    > on that session. This would then publish the message on the server.
    >
    > If that's true then I take it there is no way of rolling back a non transacted
    > session?


    For sends correct. For CLIENT_ACK receives, one has the choice of
    acknowledging or recovering the message. Recovering forces the
    message to be redelivered.


    >
    > Also for Transacted and Non-Transacted sessions at what stage are the messages
    > acknowledged
    >
    > I'd guess for a Non-Transacted session - after the message is delivered
    >
    > and for a Transacted session - after the commit occurs
    >
    > am I correct?


    Almost - in non-transacted, the message is deleted on the server after
    the message is delivered AND the client that received it
    specifically acknowledges it. Furthermore, AUTO_ACK
    is a special case - the auto-ack occurs as part of a
    the receive() for synchronous receivers, and
    after onMessage() completes for async receivers.

    Note that transacted sessions have limited applicability as
    their transactions are limited in scope to JMS operations.
    Most applications generally wish to include more than just JMS
    operations within a transaction, and in these cases,
    user transactions are preferable. For more information
    on user transactions see the JMS FAQ, as well as
    the "Transacted vs. User Transaction"
    section of the JMS Performance Guide white-paper. Both
    are available here:

    http://dev2dev.bea.com/technologies/jms/index.jsp

    Tom

    P.S. Also note that there is no point in using
    a transacted session if each transaction only includes
    one operation. In that case, you will get the
    same atomicity with a non-transacted session.

    >



  5. Re: Non-Transacted sessions

    Check out the following article that I wrote:
    http://www.javaworld.com/javaworld/j...315-jms_p.html

    The article talks about receiving end. Similar reasoning can be made on the
    sending side..

    "Barry Myles" wrote in message
    news:403c70c3$1@newsgroups.bea.com...
    >
    > Hi I wonder if someone could give me a clear and definitive answer as to

    what exactly
    > is meant by a non-transacted session, AND how does this differ from a

    transacted
    > session.
    >
    > I've had a poke about Sun's JMS Spec and still can get a handle on the

    difference
    >
    > As far as I can see it, if I develop a small Java application to send JMS

    Messages
    > to a queue, I can create a connection to the box that hosts the WLS, then

    grab
    > the initial context, look up the queue name via the connection factory,

    then go
    > on to create a session to send the messages to the queue.
    >
    > Could some one tell me what the pro's and cons of using a Transacted or

    Non-Transacted
    > session would be in this type of scenario?
    >
    > Also are the message acknowledgements still used in a transacted session?
    >
    >
    >
    >




  6. Re: Non-Transacted sessions


    Thanks guy's that's really helped alot.
    Regards,
    Barry


+ Reply to Thread