In the WebLogic server, if stateless session bean
instances are getting frequently created and removed,
performance can improved by setting a high value for
which of the following?
a. max-beans-in-free-pool
b. max-beans-in-cache
c. max-beans-in-memory
d. max-stateless-beans-in-cache
Choice A is correct. WebLogic Server maintains a free
pool of EJBs for every stateless session bean class. The
max-beans-in-free-pool element defines the size of this
pool. By default, max-beans-in-free-pool has no limit;
the maximum number of beans in the free pool is limited
only by the available memory.
When EJBs are created, the session bean instance is
created and given an identity. When the client removes a
bean, the bean instance is placed in the free pool. When
you create a subsequent bean, you can avoid object
allocation by reusing the previous instance that is in
the free pool. So the max-beans-in-free-pool element can
improve performance if EJBs are frequently created and
removed. Keeping this parameter too high uses extra
memory and keeping it too low causes unnecessary object
creation.
WebLogic Server allows you to configure the number of
active beans that are present in the EJB cache (the
in-memory space where beans exist). The
max-beans-in-cache element specifies the maximum number
of objects of this class that are allowed in memory.
When max-bean-in-cache is reached, WebLogic Server
passivates some EJBs that have not been recently used by
a client. Choices C and D are not valid properties.
How can an application do a JMS operation and have it
succeed, independent of the result of the transaction?
Basically, the JMS operation must be done using a
transacted session or the transaction must be
suspended/disabled as follows (pick one or more of the
following).
1. Suspend the current transaction prior to making the
JMS call and resume it after completing it. The code
looks something like this:
import javax.transaction.Transaction;
import javax.transaction.TransactionManager;
TransactionManager tranManager=
TxHelper.getTransactionManager();
Transaction saveTx = null;
try {
saveTx = tranManager.suspend();
... do JMS work, it will not participate in transaction
} finally {
// must always resume suspended transactions!
if (saveTx != null) tranManager.resume(saveTx);
}
2. Use a transacted session by specifying true for the
first parameter to createQueueSession or
createTopicSession.
3. Use a connection factory with user transactions
disabled. That is, check that the
UserTransactionsEnabled flag is explicitly set to false
for the connection factory in the config.xml file or use
the default for a user-configured connection factory for
this value which is false. The pre-configured connection
factory weblogic.jms.ConnectionFactory disables user
transactions.
A transacted JMS session always has its own inner
transaction. It is not affected by any transaction
context that the caller may have. A non-transacted JMS
session is more complicated. If you use the WLS 6.1
default factory weblogic.jms.ConnectionFactory, the
session does not participate in a user transaction
because the UserTransactionsEnabled flag is set to
"False". If you use the deprecated default factory
javax.jms.QueueConnectionFactory or
javax.jms.TopicConnectionFactory or you define your own
factory and set the UserTransactionsEnabled flag to
"True", the JMS session participates in the outer
transaction, if one exists and the JMS session is not
transacted.
What happens if acknowledge() is called within a
transaction?
As per the JMS specification, when you are in a
transaction, the acknowledgeMode is ignored. If
acknowledge() is called within a transaction, it is
ignored.
Is it possible to set aside a message and acknowledge it
later?
There are no special primitives for doing this. Here are
two possible solutions.
One approach is to use multiple sessions as in the
following:
while (true) {
Create a session, subscribe to one message on durable
subscription
Close session
Save session reference in memory
To acknowledge the message, find the session reference
and call
acknowledge() on it.
}
Another solution is to use transactions and suspend the
work as follows:
start transaction
while(true) {
message = receive();
if (message is one that I can handle)
process the message
commit
} else {
suspend transaction
put transaction aside with message
start transaction
}
}
To "acknowledge" the message:
resume user transaction
commit
To "recover" the message:
resume user transaction
rollback
Each time you suspend, you need to push the transaction
onto a stack or list possibly with the message so you
can process it or roll it back later. This solution is
high overhead in that there can be a large build up of
outstanding transactions. Note that transactions have
timeouts and it may rollback on its own, which means you
can get the message again (in a different transaction).
Note also that there are some practical limits on the
number of transactions you should leave outstanding. The
default limit is something like 10000. Eventually you
want to go back to your stack/list and commit/rollback
the transactions. Note that transaction references (javax.transaction.Transaction)
are not Serializable.
How should I use sorted queues?
Destination keys are used to define the sort order for a
specific destination. Destination keys can be message
header or property fields. For a list of valid message
header and property fields, refer to the Programming
WebLogic JMS.
Queues can be sorted in ascending or descending order
based on the destination key. A destination is
considered to be first-in-first-out if a destination key
is defined as ascending for the JMSMessageID message
header field, and last-in-first-out if defined as
descending. The key defined for the JMSMessageID header
field, if specified, must be the last key defined in the
list of keys.
You can define multiple destination keys to sort a
destination.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
