h3. Elements By Type
{anchor:javax.jms.ConnectionFactory-types}
h4. The _[javax.jms.ConnectionFactory|#javax.jms.ConnectionFactory-types]_ Type Implementations
    | _[<pooledConnectionFactory>|#pooledConnectionFactory-element]_ | {html}A JMS provider which pools Connection, Session and MessageProducer instances
so it can be used with tools like <a href="http://camel.apache.org/activemq.html">Camel</a> and Spring's <a
href="http://activemq.apache.org/spring-support.html">JmsTemplate and MessagListenerContainer</a>.
Connections, sessions and producers are returned to a pool after use so that they can be reused later
without having to undergo the cost of creating them again.

b>NOTE:</b> while this implementation does allow the creation of a collection of active consumers,
it does not 'pool' consumers. Pooling makes sense for connections, sessions and producers, which
are expensive to create and can remain idle a minimal cost. Consumers, on the other hand, are usually
just created at startup and left active, handling incoming messages as they come. When a consumer is
complete, it is best to close it rather than return it to a pool for later reuse: this is because,
even if a consumer is idle, ActiveMQ will keep delivering messages to the consumer's prefetch buffer,
where they'll get held until the consumer is active again.

If you are creating a collection of consumers (for example, for multi-threaded message consumption), you
might want to consider using a lower prefetch value for each consumer (e.g. 10 or 20), to ensure that
all messages don't end up going to just one of the consumers. See this FAQ entry for more detail:
http://activemq.apache.org/i-do-not-receive-messages-in-my-second-consumer.html{html} |
    | _[<xaPooledConnectionFactory>|#xaPooledConnectionFactory-element]_ | {html}A pooled connection factory which is dedicated to work with the Geronimo/Aries
transaction manager for proper recovery of in-flight transactions after a
crash.{html} |


{anchor:pooledConnectionFactory-element}
h3. The _[<pooledConnectionFactory>|#pooledConnectionFactory-element]_ Element
    {html}A JMS provider which pools Connection, Session and MessageProducer instances
so it can be used with tools like <a href="http://camel.apache.org/activemq.html">Camel</a> and Spring's <a
href="http://activemq.apache.org/spring-support.html">JmsTemplate and MessagListenerContainer</a>.
Connections, sessions and producers are returned to a pool after use so that they can be reused later
without having to undergo the cost of creating them again.

b>NOTE:</b> while this implementation does allow the creation of a collection of active consumers,
it does not 'pool' consumers. Pooling makes sense for connections, sessions and producers, which
are expensive to create and can remain idle a minimal cost. Consumers, on the other hand, are usually
just created at startup and left active, handling incoming messages as they come. When a consumer is
complete, it is best to close it rather than return it to a pool for later reuse: this is because,
even if a consumer is idle, ActiveMQ will keep delivering messages to the consumer's prefetch buffer,
where they'll get held until the consumer is active again.

If you are creating a collection of consumers (for example, for multi-threaded message consumption), you
might want to consider using a lower prefetch value for each consumer (e.g. 10 or 20), to ensure that
all messages don't end up going to just one of the consumers. See this FAQ entry for more detail:
http://activemq.apache.org/i-do-not-receive-messages-in-my-second-consumer.html{html}
h4. Properties
    || Property Name || Type || Description ||
    | blockIfSessionPoolIsFull | _boolean_ | {html}Controls the behavior of the internal session pool. By default the call to
Connection.getSession() will block if the session pool is full. If the
argument false is given, it will change the default behavior and instead the
call to getSession() will throw a JMSException.

The size of the session pool is controlled by the @see #maximumActive
property.{html} |
    | connectionFactory | _[javax.jms.ConnectionFactory|#javax.jms.ConnectionFactory-types]_ | {html}The actual JMS ConnectionFactory that will be pooled.{html} |
    | expiryTimeout | _long_ | {html}Allow connections to expire, irrespective of load or idle time. This is useful with failover
to force a reconnect from the pool, to reestablish load balancing or use of the master post recovery.{html} |
    | idleTimeout | _int_ | {html}Specifies the amount of milliseconds after which an idle connection is discarded.
Defaults to 30 seconds.{html} |
    | maxConnections | _int_ | {html}Number of JMS connections to use. The default is 1 to use a single connection
to the broker. For high throughput, it may be interesting to raise this number
a bit.{html} |
    | maximumActive | _int_ | {html}Sets the maximum number of active sessions per connection{html} |
    | poolFactory | _org.apache.commons.pool.ObjectPoolFactory_ | {html}Sets the object pool factory used to create individual session pools for
each connection{html} |

{anchor:xaPooledConnectionFactory-element}
h3. The _[<xaPooledConnectionFactory>|#xaPooledConnectionFactory-element]_ Element
    {html}A pooled connection factory which is dedicated to work with the Geronimo/Aries
transaction manager for proper recovery of in-flight transactions after a
crash.{html}
h4. Properties
    || Property Name || Type || Description ||
    | blockIfSessionPoolIsFull | _boolean_ | {html}Controls the behavior of the internal session pool. By default the call to
Connection.getSession() will block if the session pool is full. If the
argument false is given, it will change the default behavior and instead the
call to getSession() will throw a JMSException.

The size of the session pool is controlled by the @see #maximumActive
property.{html} |
    | connectionFactory | _[javax.jms.ConnectionFactory|#javax.jms.ConnectionFactory-types]_ | {html}The actual JMS ConnectionFactory that will be pooled.{html} |
    | expiryTimeout | _long_ | {html}Allow connections to expire, irrespective of load or idle time. This is useful with failover
to force a reconnect from the pool, to reestablish load balancing or use of the master post recovery.{html} |
    | idleTimeout | _int_ | {html}Specifies the amount of milliseconds after which an idle connection is discarded.
Defaults to 30 seconds.{html} |
    | maxConnections | _int_ | {html}Number of JMS connections to use. The default is 1 to use a single connection
to the broker. For high throughput, it may be interesting to raise this number
a bit.{html} |
    | maximumActive | _int_ | {html}Sets the maximum number of active sessions per connection{html} |
    | name | _java.lang.String_ | {html}The unique name for this managed XAResource. This name will be used
by the transaction manager to recover transactions.{html} |
    | poolFactory | _org.apache.commons.pool.ObjectPoolFactory_ | {html}Sets the object pool factory used to create individual session pools for
each connection{html} |
    | transactionManager | _javax.transaction.TransactionManager_ | {html}The XA TransactionManager to use to enlist the JMS sessions into.{html} |
    | xaConnectionFactory | _javax.jms.XAConnectionFactory_ | {html}{html} |

h3. Element Index
    | _[<pooledConnectionFactory>|#pooledConnectionFactory-element]_ | {html}A JMS provider which pools Connection, Session and MessageProducer instances
so it can be used with tools like <a href="http://camel.apache.org/activemq.html">Camel</a> and Spring's <a
href="http://activemq.apache.org/spring-support.html">JmsTemplate and MessagListenerContainer</a>.
Connections, sessions and producers are returned to a pool after use so that they can be reused later
without having to undergo the cost of creating them again.

b>NOTE:</b> while this implementation does allow the creation of a collection of active consumers,
it does not 'pool' consumers. Pooling makes sense for connections, sessions and producers, which
are expensive to create and can remain idle a minimal cost. Consumers, on the other hand, are usually
just created at startup and left active, handling incoming messages as they come. When a consumer is
complete, it is best to close it rather than return it to a pool for later reuse: this is because,
even if a consumer is idle, ActiveMQ will keep delivering messages to the consumer's prefetch buffer,
where they'll get held until the consumer is active again.

If you are creating a collection of consumers (for example, for multi-threaded message consumption), you
might want to consider using a lower prefetch value for each consumer (e.g. 10 or 20), to ensure that
all messages don't end up going to just one of the consumers. See this FAQ entry for more detail:
http://activemq.apache.org/i-do-not-receive-messages-in-my-second-consumer.html{html} |
    | _[<xaPooledConnectionFactory>|#xaPooledConnectionFactory-element]_ | {html}A pooled connection factory which is dedicated to work with the Geronimo/Aries
transaction manager for proper recovery of in-flight transactions after a
crash.{html} |

