How does a file store compare with a JDBC store?
The following are some similarities and differences
between file stores and JDBC stores:
* Both have the same transaction semantics, including
rolling back transactions (e.g., received messages are
put back on the queue).
* Both have the same application interface (no
difference in application code).
* The file store should be much faster.
* JDBC may make it easier to handle failure recovery
since the JDBC interface can access the database from
any client machine; with the file store, the disk must
be shared or migrated.
* File store reliability is limited to reliability of
disk and O/S; run it on Veritas or a RAID 5 system.
Database reliability may be higher.
* File stores will require more memory, but perhaps not
significantly more; it depends on how fragmented the
file store gets, if the application works roughly
* FIFO it shouldn't get very fragmented at all.
* File stores generate no additional network traffic,
database stores do if the database server is on a
different JVM or machine.
How do the WLS JMS 6.1 server/destination message
maximum and threshold values work?
The byte and message maximum values are quotas - not
flow control. Message quotas prevent a WebLogic JMS
server from filling up with messages and possibly
running out of memory, causing unexpected results. When
you reach your quota, JMS prevents further sends with a
ResourceAllocationException (rather than blocking). You
can set quotas on individual destinations or on a server
as a whole.
The thresholds are also not flow control - though they
would be better suited to that application than the
quotas. The thresholds are simply settings that when
exceeded cause a message to be logged to the console to
let you know that you are falling behind.
Note that the messages maximum setting on a connection
factory is not a quota. This specifies the maximum
numbers of outstanding messages that can exist after
they have been pushed from the server but before an
asynchronous consumer has seen them; it defaults to a
value of 10.
How do I configure JDBC so that the JMS JDBC Store
recovers automatically?
Several customers have reported a problem where they are
using a JDBC store, the DBMS goes down and back up, but
JMS can no longer use the store until WLS is shutdown
and restarted. You can get around this problem by
configuring the following attributes on the JDBC
Connection Pool associated with the JMSJDBCStore:
TestConnectionsOnReserve="true"\
TestTableName="[[[catalog.]schema.]prefix]JMSState"
If they are not set, then if the JDBC resource goes down
and comes back up, JMS cannot re-use the connection pool
until WLS is shutdown and restarted. This has been
tested against WLS 6.0 SP02 and WLS 6.1.
Does WebLogic JMS support clustering?
WebLogic JMS supports cluster-wide, transparent access
to destinations from any server in the cluster. A system
administrator can establish cluster-wide, transparent
access to destinations from any server in the cluster by
configuring multiple connection factories and using
targets to assign them to WebLogic Servers. Each
connection factory can be deployed on multiple WebLogic
Servers.
The application uses the Java Naming and Directory
Interface (JNDI) to look up a connection factory and
create a connection to establish communication with a
JMS server. Each JMS server handles requests for a set
of destinations. Requests for destinations not handled
by a JMS server are forwarded to the appropriate server.
You can configure multiple JMS servers on the various
nodes in the cluster as long as you give them different
names. You can assign destinations to the various JMS
servers.
One problem to be aware of is the propagation delay in
replicating entries in JNDI. If you have an MDB deployed
on one node but reference a destination on another node,
the deployment may fail with a
javax.naming.NamingException exception. The problem
occurs because the server is not synced up to the JNDI
from the remote server (JMS server) yet, so the JNDI
lookup of destination as part of MDB deployment will
fail. One workaround is for each MDB to reference a
local destination. Another approach is deploy the MDBs
after the server boots (plus a delay for JNDI
propagation). To get around losing messages before the
MDB is deployed, use durable subscribers. This problem
is fixed for MDBs in WLS 6.1, where the MDB will be
deployed and reconnection will be retried until the
destination is available. Note that this is still a
problem for EJBs in general that try to reference a
non-local JMS destination.
How do I do HTTP tunneling?
If you want to use HTTP tunneling (wrap every message in
HTTP to get through a firewall), you need to add
TunnelingEnabled="true" into your &lr;ver> definition in
the config.xml file or check the appropriate box on the
console. Then use a URL like http://localhost:7001
instead of t3://localhost:7001 for Context.PROVIDER_URL
when getting your InitialContext. If you want HTTP
tunneling with SSL, use https://localhost:7002 (where
https uses HTTP tunneling with SSL and 7002 is the
secure port that you configured). You will pay a
performance penalty for doing this, so only use
tunneling it if you really need to (i.e., need to go
through a firewall).
Which of the following statements are true regarding the
identity of two EJBs?
a. Two stateful session beans are identical if their
data attributes are identical.
b. Two stateful session beans are identical if their
session contexts are equal.
c. Two stateless session beans are identical if they are
of the same type.
d. Two stateless session beans are identical if their
session contexts are equal.
e. Two entity beans are identical if they have same
primary key but different home interface.
f. Two entity beans are identical if they have different
primary key but same home interface.
B and C are correct. Since the stateful session beans
maintain the conversational state of the clients, they
are identical when their session contexts are equal. Two
stateful session beans may have identical data
attributes, but if the session contexts are different
they are not identical. Thus choice A is incorrect and B
is correct. Since stateless beans do not retain the
conversational state, they are considered identical if
they are of the same type. Thus choice C is correct.
If two entity objects have the same home interface and
primary key, they are considered identical. The EJB
specification does not mention object equality based on
the = = operator. Also, if you compare two object
references using the Java API, Object.equals(Object obj),
the result is unspecified. The only way to compare
object equality is through the isIdentical (EJBObject)
API. Thus choice E and F are incorrect.
Why is my JMS work not part of a user transaction (i.e.,
called within a transaction but not rolled back
appropriately)? How do I track down transaction
problems?
Usually this problem is caused by explicitly using a
transacted session which ignores the external, global
transaction by design (JMS spec requirement). A
transacted JMS session always has its own inner
transaction. It is not affected by any transaction
context that the caller may have.
It may also be caused by using a connection factory that
is configured with "UserTransactionsEnabled" set to
false.
1. You can check if the current thread is in a
transaction by adding these two import lines:
import javax.transaction.*
import weblogic.transaction.*;
and adding the following lines (i.e., just after the
begin and just before every operation).
Transaction tran = TxHelper.getTransaction();
System.out.println(tran);
System.out.println(TxHelper.status2String(tran.getStatus()));
This should give a clear idea of when new transactions
are starting and when infection is occurring.
2. Ensure that the thread sending the JMS message is
infected with a transaction. Check that the code is not
using a transacted session by setting the first
parameter of createQueueSession or createTopicSession to
false. Note that creating the connection and/or session
is orthogonal to the transaction. You can begin your
transaction before or after. You need only start the
transaction before you send or receive messages.
3. Check that the UserTransactionsEnabled flag is
explicitly set to true for the connection factory in the
config.xml file since the default for user-configured
connection factories for this value is false. If you are
using one of the pre-configured connection factories
they are set as follows:
weblogic.jms.ConnectionFactory disables user
transactions so
don't use this one for the case where user transactions
are
desired;
javax.jms.QueueConnectionFactory and
javax.jms.TopicConnectionFactory enable user
transactions.
4. You can trace JTA operations by starting the server
with this additional property:
-Dweblogic.Debug.DebugJMSXA=true
You should see trace statements like these in the log:
XA ! XA(3163720,487900) <RM-isTransactional() ret=true>
This can be used to ensure that JMS is infected with the
transaction.
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
