Deprecation of MBeanHome and
Type-Safe Interfaces

This is a type-safe interface for a
WebLogic Server MBean, which you can import into your client
classes and access through
weblogic.management.MBeanHome. As of 9.0, the
MBeanHome interface and all type-safe interfaces for
WebLogic Server MBeans are deprecated. Instead, client classes that
interact with WebLogic Server MBeans should use standard JMX design
patterns in which clients use the
javax.management.MBeanServerConnection interface to
discover MBeans, attributes, and attribute types at runtime. For
more information, see "Developing Manageable Applications with JMX."

getDefaultTimeToDeliver()Deprecated. The number of milliseconds between when a message is produced
and when it is made visible on its target destination.

long

getDefaultTimeToLive()Deprecated. The default maximum number of milliseconds that a message will
exist.

int

getFlowInterval()Deprecated. The number of seconds (between 0 and a positive 32-bit integer)
when a producer adjusts its flow from the Flow Maximum number of
messages to the Flow Minimum amount, or vice versa.

int

getFlowMaximum()Deprecated. The maximum number of messages-per-second (between 0 and a
positive 32-bit integer) allowed for a producer that is
experiencing a threshold condition on the JMS server or queue/topic
destination.

int

getFlowMinimum()Deprecated. The minimum number of messages-per-second allowed for a producer
that is experiencing a threshold condition.

int

getFlowSteps()Deprecated. The number of steps (between 1 and a positive 32-bit integer)
used when a producer is adjusting its flow from the Flow Maximum
amount of messages to the Flow Minimum amount, or vice versa.

isServerAffinityEnabled()Deprecated. Indicates whether a server that is load balancing consumers or
producers across multiple physical destinations in a distributed
destination set will first attempt to load balance across any other
physical destinations that are also running on the same WebLogic
Server instance.

getClientId

An optional client ID for a durable subscriber that uses this
JMS connection factory. Configuring this value on the connection
factory prevents more than one JMS client from using a connection
from the factory. Generally, JMS durable subscriber applications
set their client IDs dynamically using the
javax.jms.Connection.setClientID() call.

Changes take effect after you redeploy the module or restart the server.

Default Value:

0

Maximum Value:

java.lang.Long.MAX_VALUE

Minimum Value:

0

getSendTimeout

long getSendTimeout()

Deprecated.

The maximum number of milliseconds that a sender will wait for
sufficient space (quota) on a JMS server and destination to
accommodate the message being sent. Also see the Blocking Send
Policy field on the JMS Server > Configuration > Thresholds
& Quotas tab.

Range of Values: Between 0 and a positive
64-bit integer.

The default time is 10 milliseconds. A value of
0 indicates that the sender does not want to wait for
space.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections or their producers. It only affects new connections
made with this connection factory. Producers inherit the setting
from the connection factory used to create their session and
connection. The value can then be overridden at run time by setting
the value on the producer.

Changes take effect after you redeploy the module or restart the server.

Default Value:

JMSConstants.PERSISTENT

Valid Values:

JMSConstants.PERSISTENT,JMSConstants.NON_PERSISTENT

getDefaultRedeliveryDelay

long getDefaultRedeliveryDelay()

Deprecated.

The number of milliseconds before rolled back or recovered
messages are redelivered. This value is dynamic. It can be changed
at any time. However, changing the value does not affect existing
connections. It only affects new connections made with this
connection factory.

Message consumers can get the redelivery delay explicitly by
calling the
weblogic.jms.extensions.WLSession.getRedliveryDelay()
method.

Changes take effect after you redeploy the module or restart the server.

Default Value:

0

Maximum Value:

java.lang.Long.MAX_VALUE

Minimum Value:

0

getTransactionTimeout

long getTransactionTimeout()

Deprecated.

The timeout seconds for all transactions on transacted sessions
created with this JMS connection factory. This setting has no
effect on the transaction-timeout for JTA user transactions.

Range of Values: Between 0 and a positive 32-bit
integer.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections. It only affects new connections made with this
connection factory.

Note: If a transacted session is still active after the
timeout has elapsed, the transaction is rolled back. A value of 0
indicates that the default value will be used. If you have
long-running transactions, you might want to adjust the value of
this value to allow transactions to complete.

isUserTransactionsEnabled

Specifies whether a connection factory creates sessions that are
JTA aware. If true, the associated message producers and message
consumers look into the running thread for a transaction context.
Otherwise, the current JTA transaction will be ignored. This value
is dynamic. It can be changed at any time. However, changing the
value does not affect existing connections. It only affects new
connections made with this connection factory.

Note: This value is now deprecated. If the
XAServerEnabled value is set, then this value is automatically set
as well.

Note: Transacted sessions ignore the current threads
transaction context in favor of their own internal transaction,
regardless of the setting. This setting only affects non-transacted
sessions.

Changes take effect after you redeploy the module or restart the server.

Default Value:

false

getAllowCloseInOnMessage

boolean getAllowCloseInOnMessage()

Deprecated.

Specifies whether a connection factory creates message consumers
that allow a close() or stop() method to be
issued within its onMessage() method call.

If selected (true), a close() method call from within
an onMessage() method call will succeed instead of
blocking forever. If the acknowledge mode of the session is set to
AUTO_ACKNOWLEDGE, the current message will still be
acknowledged automatically when the onMessage() call
completes.

If not selected (false), it will cause the stop() and
close() methods to hang if called from
onMessage().

Note: This value is dynamic and can be changed at any
time. However, changing the value does not affect existing
connections. It only affects new connections made with this
connection factory.

Changes take effect after you redeploy the module or restart the server.

Default Value:

false

getMessagesMaximum

int getMessagesMaximum()

Deprecated.

The maximum number of messages that may exist for an
asynchronous session and that have not yet been passed to the
message listener. A value of -1 indicates that there is no
limit on the number of messages. This value is dynamic. It can be
changed at any time. However, changing the value does not affect
existing connections. It only affects new connections made with
this connection factory. (For topic subscribers that use the
multicast extension, also see the Overrun Policy field.)

When the number of messages reaches the MessagesMaximum
value:

For multicast sessions, new messages are discarded according the
policy specified by the OverrunPolicy value and a
DataOverrunException is thrown.

For non-multicast sessions, new messages are flow-controlled, or
retained on the server until the application can accommodate the
messages.

Range of Values: Between -1
and a positive 32-bit integer.

Note: For multicast sessions, when a connection is
stopped, messages will continue to be delivered, but only until the
MessagesMaximum value is reached. Once this value is reached,
messages will be discarded based on the Overrun policy.

getOverrunPolicy

Overrun policy for topic subscribers that use the multicast
extension. The policy to use when the number of outstanding
multicast messages reaches the value specified in the Messages
Maximum field and some messages must be discarded. Keep
New indicates that the most recent messages are given priority
over the oldest messages, and the oldest messages are discarded, as
needed. Keep Old indicates that the oldest messages are
given priority over the most recent messages, and the most recent
messages are discarded, as needed. Message age is defined by the
order of receipt, not by the JMSTimestamp value.

The policy to use when the number of outstanding multicast
messages reaches the value specified in MessagesMaximum and some
messages must be discarded.

If set to Keep New, the most recent messages are
given priority over the oldest messages, and the oldest messages
are discarded, as needed.

If set to Keep Old, the oldest messages are given
priority over the most recent messages, and the most recent
messages are discarded, as needed.

Message age is defined by the order of receipt, not by the
JMSTimestamp value.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections. It only affects new connections made with this
connection factory.

Changes take effect after you redeploy the module or restart the server.

Default Value:

JMSConstants.KEEP_OLD

Valid Values:

JMSConstants.KEEP_OLD, JMSConstants.KEEP_NEW

isXAConnectionFactoryEnabled

boolean isXAConnectionFactoryEnabled()

Deprecated.

Specifies whether a XA queue or XA topic connection factory is
returned, instead of a queue or topic connection factory. An XA
factory is required for JMS applications to use JTA
user-transactions, but is not required for transacted sessions. All
connections created from an XA factory, whether they are
XAConnections or plain Connections, become JTA
user-transaction-aware.

In addition, this value indicates whether or not a connection
factory creates sessions that are JTA aware. If true, the
associated message producers and message consumers look into the
running thread for a transaction context. Otherwise, the current
JTA transaction will be ignored.

Note: Transacted sessions ignore the current threads
transaction context in favor of their own internal transaction,
regardless of the setting. This setting only affects non-transacted
sessions.

getAcknowledgePolicy

Acknowledge policy for non-transacted sessions that use the
CLIENT_ACKNOWLEDGE mode. All specifies that
calling acknowledge on a message acknowledges all unacknowledged
messages received on the session. Previous specifies that
calling acknowledge on a message acknowledges only unacknowledged
messages up to, and including, the given message.

Note: This value only applies to implementations that use
the CLIENT_ACKNOWLEDGE acknowledge mode for a
non-transacted session.

Note: This value works around a change in the JMS
specification. Specifically, the specification allowed users to
acknowledge all messages before and including the message being
acknowledged. The specification was changed so that acknowledging
any message acknowledges all messages ever received (even those
received after the message being acknowledge), as follows:

An acknowledge policy of ACKNOWLEDGE_PREVIOUS retains
the old behavior (acknowledge all message up to and including the
message being acknowledged).

An acknowledge policy of ACKNOWLEDGE_ALL yields the new
behavior, where all messages received by the given session are
acknowledged regardless of which message is being used to effect
the acknowledge.

Changes take effect after you redeploy the module or restart the server.

Default Value:

JMSConstants.ACKNOWLEDGE_ALL

Valid Values:

JMSConstants.ACKNOWLEDGE_ALL,JMSConstants.ACKNOWLEDGE_PREVIOUS

getFlowMinimum

int getFlowMinimum()

Deprecated.

The minimum number of messages-per-second allowed for a producer
that is experiencing a threshold condition. That is, WebLogic JMS
will not further slow down a producer whose message flow limit is
at its Flow Minimum.

Range of Values: Between 0 and a positive 32-bit integer.

Note: When a producer is flow controlled it will never be
required to go slower than FlowMinimum messages per second.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections.

Changes take effect after you redeploy the module or restart the server.

Default Value:

50

Maximum Value:

java.lang.Integer.MAX_VALUE

Minimum Value:

1

getFlowMaximum

int getFlowMaximum()

Deprecated.

The maximum number of messages-per-second (between 0 and a
positive 32-bit integer) allowed for a producer that is
experiencing a threshold condition on the JMS server or queue/topic
destination. When a producer is flow controlled it will never be
allowed to go faster than this number of messages per second.

If a producer is not currently limiting its flow when a
threshold condition is reached, the initial flow limit for that
producer is set to FlowMaximum. If a producer is already limiting
its flow when a threshold condition is reached (the flow limit is
less than FlowMaximum), then the producer will continue at its
current flow limit until the next time the flow is evaluated.

Note: Once a threshold condition has subsided, the
producer is not permitted to ignore its flow limit. If its flow
limit is less than the FlowMaximum, then the producer must
gradually increase its flow to the FlowMaximum each time the flow
is evaluated. When the producer finally reaches the FlowMaximum, it
can then ignore its flow limit and send without limiting its
flow.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections.

Changes take effect after you redeploy the module or restart the server.

Default Value:

60

Maximum Value:

java.lang.Integer.MAX_VALUE

Minimum Value:

0

getFlowSteps

int getFlowSteps()

Deprecated.

The number of steps (between 1 and a positive 32-bit integer)
used when a producer is adjusting its flow from the Flow Maximum
amount of messages to the Flow Minimum amount, or vice versa.

Also, the movement (i.e., the rate of adjustment) is calculated
by dividing the difference between the Flow Maximum and the Flow
Minimum into steps. At each Flow Step, the flow is adjusted upward
or downward, as necessary, based on the current conditions, as
follows:

The downward movement (the decay) is geometric over the
specified period of time (Flow Interval) and according to the
specified number of Flow Steps. (For example, 100, 50, 25,
12.5)

The movement upward is linear. The difference is simply divided
by the number of steps.

Note: This value is dynamic. It can be changed at any
time. However, changing the value does not affect existing
connections.

Changes take effect after you redeploy the module or restart the server.

Default Value:

10

Maximum Value:

java.lang.Integer.MAX_VALUE

Minimum Value:

1

isFlowControlEnabled

boolean isFlowControlEnabled()

Deprecated.

Indicates whether flow control is enabled for a producer created
using this connection factory. If true, the associated message
producers will be slowed down if the JMS server reaches
Bytes/MessagesThresholdHigh.

Changes take effect after you redeploy the module or restart the server.

Default Value:

true

isServerAffinityEnabled

boolean isServerAffinityEnabled()

Deprecated.

Indicates whether a server that is load balancing consumers or
producers across multiple physical destinations in a distributed
destination set will first attempt to load balance across any other
physical destinations that are also running on the same WebLogic
Server instance.

Copyright 1996, 2011, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.