How do I create a producer pool?
The following is some pseudo-code
for a producer class.
class ProducerPool {
static Hashmap pSets = new Hashtable();
static Hashmap inUse = new Hashtable();
QueueSender get(String contextURL,
String connectionFactoryName,
String destinationName) {
String lookup = contextURL+";
"+connectionFactName+";"+destName;
synchronized(pSets) {
producer set = pSets.get(lookup);
if (set != null && set not empty)
qs = set.removeFirst();
}
if (producer == null) {
create ctx
get connect factory
create connection
create session
look up destination
qs = create queue sender
}
synchronized(inUse) {
inUse.put(qs, lookup);
}
return qs;
}
void put(QueueSender qs) {
String lookup;
synchronized(inUse) {
lookup = inUse.remove(p);
}
synchronzied(pSets) {
producer set = pSets.get(lookup);
if (set == null) {
producer set = new producer set
pSets.put(lookup, producer set);
}
producer set.add(qs);
}
}
}
Note: Static classes may be garbage collected if there
are no references to them, so make sure the application
server has a permanent pointer to them in some manner.
One way is to reference it permanently from within a
servlet or EJB when they are initialized at startup.
Here is an example of using the producer pool within the
onMessage method.
onMessage() {
QueueSender qs = ProducerPool.get(...);
qs.send(...);
ProducerPool.put(qs);
}
You can pre-populate this pool by calling it from
a startup class or a load-on-start servlet class.
What are pending messages in the console?
Pending means the message could have been:
* sent in a transaction but not committed.
* received and not acknowledged.
* received and not committed.
* subject to a redelivery delay (as of WebLogic Server
6.1).
* subject to a delivery time (as of WebLogic Server
6.1).
A rolled back message remains pending until the
transaction actually rolls back. Rolling it back
multiple times does not cause double counting, nor does
an exception that set a transaction as rollbackOnly
followed by an actual rollback.
Current implies messages that are not pending.
Total implies total since server last started. The byte
counts only consider the payload of messages which
includes the properties and the body but not the header.
How do I use a less than or greater than on a message
selector in ejb-jar.xml?
Enclose the selector in a CDATA section. That will
prevent the XML parser from thinking that less than or
greater than is a tag.
<jms-message-selector>
<![CDATA[ JMSXAppID <> 'user' ]]>
</jms-message-selector>
Is it better to have more or fewer sessions for a given
number of subscribers?
Using N sessions for N subscribers gives you concurrency
up to N simultaneous threads of execution provided you
have as many threads to work with. Each Session gets its
own thread as long as there are enough threads
available. Otherwise, the sessions serially reuse the
available threads.
One session for N subscribers serializes all subscribers
through that one session. If the load is heavy they may
not be able to keep up without the extra threads.
If you are using CLIENT_ACKNOWLEDGE, N sessions gives
you N separate message streams that can be individually
recovered. Having one session crosses the streams giving
you less control.
Match the EJB functions given below with the
functionality equivalent in SQL
A.) ejbStore() 1.) INSERT
B.) ejbLoad() 2.) UPDATE
C.) ejbCreate() 3.) SELECT
a. A->1, B->2, C->3
b. A->2, B->1, C->3
c. A->3, B->2, C->1
d. A->1, B->3, C->2
e. A->2, B->3, C->1
f. A->3, B->1, C->2
Choice E is correct. When the create() method on a home
interface is invoked, the container delegates the
create() method call to the bean instance's matching
ejbCreate() method. The ejbCreate() methods are used to
initialize the instance state before record is inserted
into the database. The ejbCreate() method is analogous
to INSERT. The ejbStore() method is invoked just before
the container the container is about to write the bean
container-managed fields to the database. It is
analogous to the UPDATE . The ejbLoad() is invoked just
after the container has refreshed the bean
container-managed files with its state from the
database. It is analogous to the SELECT. Thus choice E
is correct and others are not.
A client invokes a method on a stateful session bean
instance deployed in the WebLogic Server. While the
method execution is in progress another method call
arrives on the server. What will be the result?
a. RemoteException is thrown if the value of
concurrency-strategy property is false
b. EJBException is thrown if the value of
concurrency-strategy property is false
c. The EJB container blocks the concurrent method call
and allows it to proceed when the previous call has
completed if the value of allow-concurrent-calls is true
d. In all cases, RemoteException is thrown
Choice C is correct. By default, simultaneous access to
a stateful session EJB results in a RemoteException.
However, you can set the allow-concurrent-calls option
in the WebLogic EJB deployment descriptor to specify
that a stateful session bean instance will allow
concurrent method calls. This access restriction on
stateful session EJBs applies whether the EJB client is
remote or internal to WebLogic Server. By default,
allows-concurrent-calls is false. However, when this
value is set to true, the EJB container blocks the
concurrent method call and allows it to proceed when the
previous call has completed.
The concurrency-strategy element determines ejbLoad()
and ejbStore() behavior for entity EJB instances.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
