Examples of ActiveMQSession

org.activemq.ActiveMQSession
A Session object is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine (JVM), it is considered a lightweight JMS object.
A session serves several purposes:
- It is a factory for its message producers and consumers.
- It supplies provider-optimized message factories.
- It is a factory for TemporaryTopics and TemporaryQueues.
- It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
- It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
- It defines a serial order for the messages it consumes and the messages it produces.
- It retains messages it consumes until they have been acknowledged.
- It serializes execution of message listeners registered with its message consumers.
- It is a factory for QueueBrowsers.
A session can create and service multiple message producers and consumers.
One typical use is to have a thread block on a synchronous MessageConsumer until a message arrives. The thread may then use one or more of the Session'sMessageProducers.
If a client desires to have one thread produce messages while others consume them, the client should use a separate session for its producing thread.
Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection close method.
It should be easy for most clients to partition their work naturally into sessions. This model allows clients to start simply and incrementally add message processing complexity as their need for concurrency grows.
The close method is the only session method that can be called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.
The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.
A transaction is completed using either its session's commit method or its session's rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
The Java Transaction Service (JTS) or some other transaction monitor may be used to combine a session's transaction with transactions on other resources (databases, other JMS sessions, etc.). Since Java distributed transactions are controlled via the Java Transaction API (JTA), use of the session's commit and rollback methods in this context is prohibited.
The JMS API does not require support for JTA; however, it does define how a provider supplies this support.
Although it is also possible for a JMS client to handle distributed transactions directly, it is unlikely that many JMS clients will do this. Support for JTA in the JMS API is targeted at systems vendors who will be integrating the JMS API into their application server products. @version $Revision: 1.1.1.1 $ @see javax.jms.Session @see javax.jms.QueueSession @see javax.jms.TopicSession @see javax.jms.XASession
org.apache.activemq.ActiveMQSession
A Session object is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine (JVM), it is considered a lightweight JMS object.
A session serves several purposes:
- It is a factory for its message producers and consumers.
- It supplies provider-optimized message factories.
- It is a factory for TemporaryTopics and TemporaryQueues.
- It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
- It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
- It defines a serial order for the messages it consumes and the messages it produces.
- It retains messages it consumes until they have been acknowledged.
- It serializes execution of message listeners registered with its message consumers.
- It is a factory for QueueBrowsers.
A session can create and service multiple message producers and consumers.
One typical use is to have a thread block on a synchronous MessageConsumer until a message arrives. The thread may then use one or more of the Session'sMessageProducers.
If a client desires to have one thread produce messages while others consume them, the client should use a separate session for its producing thread.
Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection close method.
It should be easy for most clients to partition their work naturally into sessions. This model allows clients to start simply and incrementally add message processing complexity as their need for concurrency grows.
The close method is the only session method that can be called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.
The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.
A transaction is completed using either its session's commit method or its session's rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
The Java Transaction Service (JTS) or some other transaction monitor may be used to combine a session's transaction with transactions on other resources (databases, other JMS sessions, etc.). Since Java distributed transactions are controlled via the Java Transaction API (JTA), use of the session's commit and rollback methods in this context is prohibited.
The JMS API does not require support for JTA; however, it does define how a provider supplies this support.
Although it is also possible for a JMS client to handle distributed transactions directly, it is unlikely that many JMS clients will do this. Support for JTA in the JMS API is targeted at systems vendors who will be integrating the JMS API into their application server products. @version $Revision: 1.34 $ @see javax.jms.Session @see javax.jms.QueueSession @see javax.jms.TopicSession @see javax.jms.XASession
org.codehaus.activemq.ActiveMQSession
A Session object is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine (JVM), it is considered a lightweight JMS object.
A session serves several purposes:
- It is a factory for its message producers and consumers.
- It supplies provider-optimized message factories.
- It is a factory for TemporaryTopics and TemporaryQueues.
- It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
- It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
- It defines a serial order for the messages it consumes and the messages it produces.
- It retains messages it consumes until they have been acknowledged.
- It serializes execution of message listeners registered with its message consumers.
- It is a factory for QueueBrowsers.
A session can create and service multiple message producers and consumers.
One typical use is to have a thread block on a synchronous MessageConsumer until a message arrives. The thread may then use one or more of the Session'sMessageProducers.
If a client desires to have one thread produce messages while others consume them, the client should use a separate session for its producing thread.
Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection close method.
It should be easy for most clients to partition their work naturally into sessions. This model allows clients to start simply and incrementally add message processing complexity as their need for concurrency grows.
The close method is the only session method that can be called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.
The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.
A transaction is completed using either its session's commit method or its session's rollback method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
The Java Transaction Service (JTS) or some other transaction monitor may be used to combine a session's transaction with transactions on other resources (databases, other JMS sessions, etc.). Since Java distributed transactions are controlled via the Java Transaction API (JTA), use of the session's commit and rollback methods in this context is prohibited.
The JMS API does not require support for JTA; however, it does define how a provider supplies this support.
Although it is also possible for a JMS client to handle distributed transactions directly, it is unlikely that many JMS clients will do this. Support for JTA in the JMS API is targeted at systems vendors who will be integrating the JMS API into their application server products. @version $Revision: 1.11.2.1 $ @see javax.jms.Session @see javax.jms.QueueSession @see javax.jms.TopicSession @see javax.jms.XASession

Examples of org.apache.activemq.ActiveMQSession

     */
    private ManagedSessionProxy createSessionProxy(boolean transacted, int acknowledgeMode) throws JMSException {
        if (!transacted && acknowledgeMode == Session.SESSION_TRANSACTED) {
            acknowledgeMode = Session.AUTO_ACKNOWLEDGE;
        }
        ActiveMQSession session = (ActiveMQSession) getConnection().createSession(transacted, acknowledgeMode);
        ManagedTransactionContext txContext = new ManagedTransactionContext(managedConnection.getTransactionContext());
        session.setTransactionContext(txContext);
        ManagedSessionProxy p = new ManagedSessionProxy(session, this);
        p.setUseSharedTxContext(managedConnection.isInManagedTx());
        synchronized (sessions) {
            sessions.add(p);
        }

View Full Code Here

Examples of org.apache.activemq.ActiveMQSession


        // Create consumer on separate connection
        ActiveMQConnection consumerConnection = (ActiveMQConnection) cf.createConnection();
        consumerConnection.setMessagePrioritySupported(true);
        consumerConnection.start();
        final ActiveMQSession consumerSession = (ActiveMQSession) consumerConnection.createSession(true,
                Session.SESSION_TRANSACTED);
        consumer = (ActiveMQMessageConsumer) consumerSession.createConsumer(dest);


        // Produce X number of messages with a session commit after each message
        Random random = new Random();
        for (int i = 0; i < messageCount; ++i) {


            Message message = producerSession.createTextMessage("Test message #" + i);
            producer.send(message, DeliveryMode.PERSISTENT, random.nextInt(10), 45*1000);
            producerSession.commit();
        }
        producer.close();


        // ***************************************************
        // If we create the consumer here instead of above, the
        // the messages will be consumed in priority order
        // ***************************************************
        //consumer = (ActiveMQMessageConsumer) consumerSession.createConsumer(dest);


        // Consume all of the messages we produce using a listener.
        // Don't exit until we get all the messages.
        final CountDownLatch latch = new CountDownLatch(messageCount);
        final StringBuffer failureMessage = new StringBuffer();
        consumer.setMessageListener(new MessageListener() {
            int lowestPrioritySeen = 10;


            boolean firstMessage = true;


            public void onMessage(Message msg) {
                try {


                    int currentPriority = msg.getJMSPriority();
                    LOG.debug(currentPriority + "<=" + lowestPrioritySeen);


                    // Ignore the first message priority since it is prefetched
                    // and is out of order by design
                    if (firstMessage == true) {
                        firstMessage = false;
                        LOG.debug("Ignoring first message since it was prefetched");


                    } else {


                        // Verify that we never see a priority higher than the
                        // lowest
                        // priority seen
                        if (lowestPrioritySeen > currentPriority) {
                            lowestPrioritySeen = currentPriority;
                        }
                        if (lowestPrioritySeen < currentPriority) {
                            failureMessage.append("Incorrect priority seen (Lowest Priority = " + lowestPrioritySeen
                                    + " Current Priority = " + currentPriority + ")"
                                    + System.getProperty("line.separator"));
                        }
                    }


                } catch (JMSException e) {
                    e.printStackTrace();
                } finally {
                    latch.countDown();
                    LOG.debug("Messages remaining = " + latch.getCount());
                }
            }
        });


        latch.await();
        consumer.close();


        // Cleanup producer resources
        producerSession.close();
        producerConnection.stop();
        producerConnection.close();


        // Cleanup consumer resources
        consumerSession.close();
        consumerConnection.stop();
        consumerConnection.close();


        // Report the failure if found
        if (failureMessage.length() > 0) {

View Full Code Here

Examples of org.codehaus.activemq.ActiveMQSession

    private void createSession() throws ResourceException {
        try {
            physicalSession = physicalConnection
                    .createSession(true, Session.SESSION_TRANSACTED);
            if (physicalSession instanceof ActiveMQSession) {
                ActiveMQSession session = (ActiveMQSession) physicalSession;
                LocalTransactionEventListener l = createLocalTransactionEventListener();
                session.setLocalTransactionEventListener(l);
            }
            else {
                log.trace("Cannot register LocalTransactionEventLister on non-ActiveMQ session");
            }

View Full Code Here

0 1 2 3 4 5

TOP

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.