1. Why does FOR UPDATE in Oracle 8 cause an ORA-01002 error?
The Oracle 8 server generates an ORA-01002:fetch out of sequence error message when you use a FOR UPDATE statement with AUTOCOMMIT turned on (which is the default state when using JDBC). This is known to happen on Oracle 8.0 and 8.1 on Solaris and on Oracle 8.1 on Windows NT. If you turn AUTOCOMMIT off, you will not receive this error. Because this problem is due to a change in the Oracle 8 server, you should contact Oracle support for more information.
2. How can I control on which WebLogic Server(s) my application will run?
A system administrator can specify on which WebLogic Server(s) applications will run by specifying targets when configuring connection factories. Each connection factory can be deployed on multiple WebLogic servers.
Note: If you use the default connection factory, you have no control over the WebLogic server on which the connection factory may be deployed. If you would like to target a particular WebLogic server, create a new connection factory and specify the appropriate JMS server target(s).
3. How do I look up an ORA SQLException?
If your WebLogic jDriver for Oracle application produces an SQLException such as:
java.sql.SQLException: ORA-12536: TNS: operation would block
You can look up an Oracle error by using the oerr command. For example, the description of error ORA-12536 can be found with the command:
> oerr ora 12536
4. How do I use Unicode codesets with the WebLogic jDriver for Oracle driver?
To use Unicode codesets:
1. Install the appropriate codeset when you install Oracle. If you did not do this in the original installation, you will need to re-run the Oracle installer and install the proper codeset.
2. Define the NLS_LANG variable in the environment where the JDBC driver is running. Do this by assigning the proper codeset to NLS_LANG in the shell from where you start the WebLogic Server.
The Developers Guide has more information about internationalization support.
Yes. Use the setAttribute() method for SAX mode parsing and the getAttribute() method for DOM mode parsing. Using these methods in a Servlet, however, is a WebLogic-specific feature. This means that the Servlet may not be fully portable to other Servlet engines, so use the feature with caution.
The WL-Proxy-Client-Cert header can be spoofed (used) by any client which has direct access to WebLogic Server. WebLogic Server takes the certificate information from that header, trusting that is came from a secure source (the plug-in) and use that information to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust that header. Now you need to explicitly define trust of the WL-Proxy-Client-Cert header. A new parameter clientCertProxy allows WebLogic Server to on the implicit trust of the certificate header. If you need an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).
The clientCertProxy parameter has been added to the HTTPClusterServlet and Web applications.
For the HTTPClusterServlet, add the parameter to the web.xml file as follows:
<context-param>
<param-name>clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
For Web applications, add the parameter to the web.xml file as follows:
ServletRequestImpl context-param
<context-param>
<param-name>weblogic.http.clientCertProxy</param-name>
<param-value>true</param-value>
</context-param>
You can also use this parameter in a cluster as follows:
<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"
ClientCertProxyHeader="true"/>
7. How can I run multiple instances of the same servlet class in the same WebLogic Server instance?
If you want to run multiple instances, your servlet will have to implement the SingleThreadModel interface. An instance of a class that implements the SingleThreadModel interface is guaranteed not to be invoked by multiple threads simultaneously. Multiple instances of a SingleThreadModel interface are used to service simultaneous requests, each running in a single thread.
When designing your servlet, consider how you use shared resources outside of the servlet class such as file and database access. Because there are multiple instances of servlets that are identical, and may use exactly the same resources, there are still synchronization and sharing issues that must be resolved, even if you do implement the SingleThreadModel interface.
8. How do I identify the document type of an XML document?
If the XML document has a Public ID, then that is its document type. For example, if an XML document contains the following DOCTYPE declaration:
<!DOCTYPE mydoc PUBLIC "My public ID String"
"http://foo.com/url/to/my/dtd">
then its document type is My public ID String.
If the DOCTYPE declaration does not contain a Public ID, but specifies a System ID, then the document type is the System ID. For example, in the following DOCTYPE declaration:
<!DOCTYPE mydoc SYSTEM "http://foo.com/url/to/my/dtd">
the document type is http://foo.com/url/to/my/dtd.
Note: The System ID is of the DTD, not of the XML document itself. It can, however, still be used as a way to identify the XML document.
If the XML document does not specify a DOCTYPE declaration, then the document type can be either the root element name or the namespace URI, if it has one.
a. In case of a MDB, developer needs to create a MessageListener class that utilizes a server-wide session pool.
b. WebLogic Server container provides standard EJB services to MDBs.
c. MDBs benefit from the write-once, deploy-anywhere paradigm of EJBs.
d. MDBs can be associated with multiple Messaging Queues or Topics unlike standard JMS.
Choices B and C are correct. A message-driven bean is a special kind of EJB that acts as a message consumer in the WebLogic JMS messaging system. As with standard JMS message consumers, message-driven beans receive messages from a JMS Queue or Topic, and perform business logic based on the message contents. EJB deployers create listeners to a Queue or Topic at deployment time, and WebLogic Server automatically creates and removes message-driven bean instances as needed to process incoming messages.
Because message-driven beans are implemented as EJBs, they benefit from several key services that are not available to standard JMS consumers. Most importantly, message-driven bean instances are wholly managed by the WebLogic Server EJB container. Using a single message-driven bean class, WebLogic Server creates multiple EJB instances as necessary to process large volumes of messages concurrently. This stands in contrast to a standard JMS messaging system, where the developer must create a MessageListener class that utilizes a server-wide session pool. Thus choice A is incorrect.
WebLogic Server provides standard EJB services to MDBs, such as security services and automatic transaction management. Thus choice B is correct.
Being implemented as EJBs, MDBS benefit from the write-once, deploy-anywhere quality of EJBs. Whereas a JMS MessageListener is tied to specific session pools, Queues, or Topics, message-driven beans can be developed independently of available server resources. Thus Choice C is also correct.
Its not that MDBs are always advantageous as compared to standard JMS consumers. One limitation of MDBs compared to standard JMS listeners is that a given MDB deployment can be associated with only one Queue or Topic. If your application requires a single JMS consumer to service messages from multiple Queues or Topics, you must use a standard JMS consumer, or deploy multiple message-driven bean classes. Thus Choice D is incorrect.
10. How can I debug the Java code that I have running in WebLogic Server?
You can use tools such as WebGain, JBuilder, NetBeans and JDB that rely on the Java Platform Debugger Architecture (JPDA) to debug your Java code running in WebLogic Server.
JPDA is integrated in the Java 2 Platform, Standard Edition (J2SE) SDK 1.3 on all platforms and SDK 1.2.2 for Linux. There is a download available from Sun to add JPDA support to the J2SE SDK 1.2.2 on Solaris and Microsoft Window platforms. If you are using J2SE SDK 1.2.2 on these platforms you must first get this download.
To allow a debugger to attach to the virtual machine that WebLogic runs you have to start WebLogic in debug mode. In order to start WebLogic in debug mode using a Sun virtual machine follow these steps (start with step one only if using a Solaris platform):
1. If using a Solaris platform, change the LD_LIBRARY_PATH environment variable to prepend $JAVA_HOME/lib/sparc:
export LD_LIBRARY_PATH=$JAVA_HOME/lib/sparc:$LD_LIBRARY_PATH
2. Add the following parameters to the java command line (before the "weblogic.Server" string) that launches WebLogic server:
-Xdebug
-Xnoagent
-Xrunjdwp:transport=dt_socket
server=y
address=<port_for_debugger_to_connect>
suspend=n
-Djava.compiler=NONE
Note that with the Hotspot Performance engine the -Xnoagent and -Djava.compiler=NONE options are no longer required, but are accepted and ignored for compatibility reasons.
If server=y and no address parameter is supplied, WebLogic Server chooses the transport address and prints it to the standard output stream. So, if a line such as:
Listening for transport dt_socket at address: 46666
prints in your standard output stream when the server starts, the number 46666 is the port number to be supplied to your tool's remote debugger in order to attach it to WebLogic's virutal machine.
11. How do an RMI-IIOP application and an existing CORBA object interoperate?
If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces.
For example, to interoperate between an RMI-IIOP client and a C++ object you need to:
1. Define the remote interface of the object in Java as an RMI interface.
2. Run rmic -iiop against the interface to produce the stub for your RMI-IIOP client.
3. Run rmic -idl against the interface to produce IDL compatible with the RMI interface.
4. Run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object.
12. What causes Java.io exceptions in the log file?
You may see messages like these in the log file:
(Windows NT)
java.io.IOException Connection Reset by Peer
java.io.EOFException Connection Reset by Peer
(Solaris)
java.io.Exception: Broken pipe
These messages occur when you are using servlets. A client initiates an HTTP request, and then performs a series of actions on the browser:
1. Click Stop or enter equivalent command or keystrokes
2. Click Refresh or enter equivalent command or keystrokes
3. Send a new HTTP request.
The messages indicate that WebLogic Server has detected and recovered from an interrupted HTTP request.
1:
2:
3:
My Progress Report
4:
5: <% score++; %>
6: <%= "My score is : " + score %>
7:
8:
a. <%! int score = 99; %>
` b. <% int score; %> `
c. <%@ int score = 99; %>
` d. < int score = 99; />
A is the correct choice. The above JSP will work on declaring and initializing the variable score. The syntax for declaring and initializing a variable in JSP is as follows:
<%! variable=variable_value ; %>
Thus A is the correct choice. The <%@ ... %> tag is used to declare directives like include directive. Thus choice C is incorrect. The <% ... %> code is used to insert scriptlets (lines of code in java) like the one at line 5. The code written inside the scriptlet becomes part of the service() method of the generated servlet. Thus 'score' becomes the local variable of the service method. And for this JSP to compile properly, the variable 'score' should have been initialized. If "<% int score; %>" is replaced by "<% int score=99; %>" , the choice B would also be correct. In the present scenario, the choice B will give compilation error saying "Variable score may not have been initialized". Choice D is incorrect as it's not a valid tag.
14. Which is the only method defined in the javax.ejb.Handle interface?
a. getEJBHome
b. getEJBObject
c. getPrimaryKey
d. getHomeHandle
Choice B is correct. The Handle is a serializable reference to the EJBObject. The EJBObject.getHandle() method returns a Handle object. The Handle allows us to recreate an EJB object remote reference that points to the same type of session bean or the same unique bean that the handle came from.
The Handle interface specifies only one method, getEJBObject(). Calling this method returns the EJB Object from which the handle was created. After getting the object back, we can narrow or cast it to the appropriate remote interface type. The getEJBHome method is defined in the HomeHandle interface and the getPrimaryKey method in the EntityContext interface. The getHomeHandle method is defined in the EJBHome interface.
a. beforeBegin
b. afterBegin
c. beforeCompletion
d. afterCompletion
Choices B, C and D are correct. A stateful session bean using container-managed transactions can implement the javax.ejb.SessionSynchronization interface to provide transaction synchronization notifications. This interface defines only 3 methods - afterBegin(), beforeCompletion() and afterCompletion().
The afterBegin() callback method is called when the bean becomes part of a transaction. It is called before the EJB Object delegates the business method invocation to the bean instance. If the transaction is committed, the bean will be notified through its beforeCompletion() method. If the transaction is rolled back, this method is not invoked. The afterCompletion() method is always invoked whether the transaction ended with a commit or a rollback. A is incorrect because beforeBegin is not a method defined in the SessionSynchronization interface.
16. Can WebLogic Server start with a UNIX boot?
You can add a startup script to your UNIX rc scripts to run WebLogic Server at UNIX boot time. Here is an example from an HP-UX 11 system, running under JDK 1.1. You need to supply the URL for your WebLogic Server and your system password. This file, wlstart, is placed in the /sbin/init.d directory and there is a link to it in the /sbin/rc2.d directory:
export SHLIB_PATH=
/home/user1/weblogic/lib/hpux11:/oracle/8.0.4/lib
export CLASSPATH=/home/user1/weblogic/classes:
/home/user1/weblogic/lib/weblogicaux.jar
export ORACLE_HOME=/oracle/8.0.4
export ORACLE_SID=DEMO
export ORACLE_TERM=vt100
export QAT=/home/user1/weblogic
cd $QAT
PATH=/sbin:/usr/sbin:/usr/bin:/opt/java/bin
export PATH
case $1 in
'start')
java -ms64m -mx64m -verbosegc weblogic.Server >
/home/user1/weblogic/server.out 2> #emp;
;;
'stop')
java weblogic.Admin URL shutdown system password
;;
*)
echo "usage: $0 {start|stop}"
;;
esac
You should work with your UNIX system administrator to set up scripts similar to this for your system.
17. How do I configure WebLogic to use a SOCKS proxy?
You can configure a java.net socket to use SOCKS by setting a Java system property.
18. Which of the following programs can be created using the ZAC Publish Wizard tool?
Choices:
a. Installer
b. Deployer
c. Bootstrap
d. Packager
Choices A and C are correct. To publish to a WebLogic Server, we can use the ZAC publish wizard. For this, the server must be running, and you will need to know a user and password that has permission to publish. You can also use the ZAC Publish Wizard to create a set of native programs - an installer and a bootstrap - for various operating systems that become part of a published Java application.
The installer program is a native executable that installs your published Java program on the local machine. It doesn't require a Java environment itself, so it can run out-of-the-box in the native OS. The bootstrap is also a native program; the user runs the bootstrap to invoke the published application. The bootstrap takes care of monitoring for updates, downloading and updating the user's application, and other administrative ZAC functions.
a. JTA
b. JNDI
c. JMS
d. JTS
e. JMX
Choice B is correct. WebLogic Server supports the javax.transaction package and the javax.transaction.xa package, which implement the Java Transaction API (JTA) for Java applications.
javax.transaction.UserTransaction provides an interface to the transaction manager that allows the application developer to manage the scope of a transaction explicitly. The client application uses JNDI to obtain an object reference to the UserTransaction object for the WebLogic Server domain.
The code used by the client is given.
UserTransaction ut=(UserTransaction)jndicontext.lookup("javax.transaction.UserTransaction")
If a bean needs a reference to the UserTransaction object, it obtains it from the EJBContext as given.
UserTransaction ut=ejbContext.getUserTransaction()
20. How do I enable debugging for the messaging bridge?
You can enable debugging for the messaging bridge using either of the followings methods:
* Add the following lines to your WebLogic start script (before the weblogic.Server line):
-Dweblogic.Debug.DebugMessagingBridgeStartup=true
-Dweblogic.Debug.DebugMessagingBridgeRuntime=true
* Add the following statements to the ServerDebug entry in your configuration file (config.xml) for the server that the messaging bridge is running on:
DebugMessagingBridgeStartup="true"
DebugMessagingBridgeRuntime="true"
Once debugging is enabled for the messaging bridge, the debugging messages are sent to the server log by default. However, if you want them to appear in the Administration Console, add "DumpToConsole" to the statements show above. For example:
-Dweblogic.Debug.DebugMessagingBridgeStartupDumpToConsole=true
Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running on release 6.1 or later. When connecting to either a source or target destination that is running on release 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider's CLASSPATH in the WebLogic Server CLASSPATH.
There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:
* The supported adapters are located in the WL_HOMElib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 6.1 domain where the bridge is running, via the select Deployments -> Applications node on the console.
* This jms-xa-adp.rar adapter must also be identified in the Adapter JNDI Name attribute as eis.jms.WLSConnectionFactoryJNDIXA on the JMS Bridge Destination -> Configuration tab for both the source and target bridge destinations.
* For WebLogic JMS, verify that you are using the transactional XAConnectionFactory for the queue or topic destinations mapped to both the source and target bridge destinations. To verify this, the following attributes must be set on the JMS -> Connection Factory -> Configuration -> Transactions console tab or in the configuration file (config.xml):
UserTransactionsEnabled=true
XAConnectionFactory=true
* For third-party JMS vendors, verify that you are using a transactional connection factory for the destinations mapped to the source and target bridge destinations.
23. Why did the messaging bridge fail to connect to the source bridge destination?
Either an error occurred when configuring the source bridge destination parameters, or the actual source destination is not running and cannot communicate with the messaging bridge.
* Verify whether the bridge's source destination is correctly configured, by making sure that the following fields on the JMS Bridge Destination -> Configuration -> General console page have been properly completed:
o Connection URL-this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
o Destination JNDI Name-this must be the JNDI name of the actual destination mapped to the source bridge destination.
o Connection Factory JNDI Name-this must be the connection factory used to create a connection for the actual destination mapped to the source bridge destination.
o User Name/Password-make sure that this user ID has permission to access the actual source destination.
* Verify that the actual source queue or topic destination mapped to the source bridge destination is running and healthy, as follows:
o Is the WebLogic Server instance hosting the source destination running?
o Is the JMS server hosting the source destination correctly deployed?
Note: This troubleshooting scenario for correcting a source bridge destination connection failure also applies to target bridge destinations.
24. Can you use a foreign JMS provider to drive an MDB transactionally?
No. The message is asynchronously received outside a transaction and there is no J2EE API to then associate the message with a transaction.
The only reason this works for WebLogic Server JMS is that we have defined a WebLogic Server extension interface that has a method to associate a message with a transaction. This interface, MDBTransaction, is defined in news://newsgroups.bea.com/3b3a009b$1@newsgroups.bea.com. It has one method, associateTransaction(), that takes a javax.jms.Message parameter. This message must be associated with the transaction. We are hoping that other JMS vendors interested in integrating with WebLogic Server will implement this interface.
Another approach called source managed transactions, would be for there to be an API to tell the JMS provider to start a transaction on your behalf before delivering the message to an asynchronous consumer. This API doesn't exist in J2EE either. Even if there were such a provision, few non-WLS JMS providers can begin and drive such a transaction by themselves.
The current solution is to move all messages from the foreign destination to a WebLogic Server JMS destination (within a transaction if the foreign JMS provider supports it) and have that WebLogic Server JMS destination drive the MDB transactionally (using the WLS JMS special interface). Currently, the messages can be moved between providers using code similar to that described in the "Using Foreign JMS Providers With WebLogic Server" white paper. This code could be contained in a startup class that starts a thread and does the following:
while (true) {
start a transaction
receive a message synchronously with timeout
if timed_out { rollback and continue }
do the work
commit the transaction }
Doing a synchronous receive will have a problem in that the transaction may time out before the message is received. You can do the receive with a specified timeout, allowing enough time left in the transaction to complete the work. If the receive fails, roll back the transaction and try again. It is also not as efficient as MDBs since it does a synchronous instead of asynchronous receive (it ties up threads). Also, if you get a lot of timeouts, you will be burning more CPU.
Eventually, WLS JMS will provide a bridge to handle this message passing out-of-the box.
With any of these approaches, the XAResource must be registered with the Transaction Manager (this is done automatically for WebLogic Server JMS).
25. Which of the following are valid relationships between JMS objects in the WebLogic Server?
a. A single JMS store can support multiple JMS servers.
b. Multiple consumers may consume from the same queue, but multiple producers may not send to the same queue.
c. Multiple JMS Servers may exist on one WebLogic 6.0 server.
d. A JMS Server can be deployed on only one server.
Choices C and D correct. JMS is an enterprise messaging system, which enables applications to communicate with one another through the exchange of messages. WebLogic JMS provides a full implementation of the JMS API.JMS objects are the objects necessary to connect to the JMS, and send and receive messages.
The major components of the WebLogic JMS Server architecture include WebLogic JMS servers implementing the messaging facility, Client applications, JNDI and Backing stores (file or database) for storing persistent data. Two or more JMS servers cannot share the same persistent store. Each JMS server must have its own unique persistent store. Two file-based JMS persistent stores may share the same directory, but their messages will be stored in different files. Multiple consumers may consume from the same queue and multiple producers may send messaged to the same queue. Multiple JMS servers may exist on the same WebLogic server, but a JMS server can be deployed only on server at a time.
26. How can I avoid asynchronous message deadlocks?
Due to a limitation in the JMS 1.0.2 specification, asynchronous messages can become deadlocked if the close() method of a session is inside a user-synchronized block. To resolve this, you must move the close() method outside the user-synchronized block. For example:
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
connection.close();
}
}
private void onMessage(Message message) {
synchronized (this) {
notify();
}
}
}
Before the connection.close() method is closed, another message can be delivered to the onMessage routine by the JMSProvider. The main() method thread owns the monitor lock for the CloseTest method. Before the onMessage() method of the CloseTest class fires, JMS sets INLISTENER as the state for the session in JMSSession (the JMS specification says that the close() method must wait for the onMessage routine), so that the main() method thread can wait for the onMessage routine to complete.
Now when the onMessage routine tries to acquire the monitor lock, it blocks waiting for the main() method thread to give up, and the main() method thread is waiting for the onMessage to be completed.
JMS also blocks when the close() method of a consumer is done from an onMessage routine and the allowCloseInOnMessage attribute is set to false in the config.xml file.
27. Which of the following is NOT true about deploying EJBs in the WebLogic Server?
a. The weblogic/config/examples/applications directory acts as an automatic deployment directory for EJB 2.0 .jar files and EJB .jar deployment directories
b. The automatic redeployment feature of the WebLogic Server can only redeploy an EJB's implementation classes, you cannot redeploy an EJB's public interfaces
c. Before deploying a packaged jar file containing uncompiled EJB classes and interfaces, we have to use weblogic.ejbc on the packaged .jar file to generate WebLogic Server container classes.
Choice C is correct because it is NOT true. A and B are true about deploying EJBs in the WebLogic server. The weblogic/config/examples/applications directory acts as an automatic deployment directory for EJB 2.0 .jar files and EJB .jar deployment directories. When you start WebLogic Server, it automatically deploys any valid EJB 2.0 .jar files or .jar directories that reside in the applications directory. WebLogic Server also checks the contents of applications every ten seconds to determine whether an EJB deployment has changed. If a deployment has changed, it is automatically redeployed using the dynamic deployment feature.
If you change the contents of a compiled EJB .jar file in applications, WebLogic Server automatically attempts to redeploy the .jar using the dynamic deployment feature. Since the automatic redeployment feature uses dynamic deployment, WebLogic Server can only redeploy an EJB's implementation classes. You cannot redeploy an EJB's public interfaces. You create compiled EJB 2.0 .jar files by Compiling your EJB classes and interfaces, packaging the EJB classes and interfaces into a valid .jar file and then Using weblogic.ejbc on the .jar file to generate WebLogic Server container classes. An uncompiled EJB .jar file has the same structure as a compiled file, but you do not have to compile individual class files and interfaces and you do not have to use weblogic.ejbc on the packaged .jar file to generate WebLogic Server container classes. So C is not true.
Yes, with one caveat. You may not add new subscribers/consumers to a session if it already has active async consumers. Sessions must only be accessed single-threaded as per the JMS spec. If you feel you need to do this, create a new Session and add it to that one instead.
You can add receivers to a started connection. A receiver in itself is not asynchronous. You need a listener to make it asynchronous. The first creation of a receiver is always safe. If you then add a listener for that first receiver, you have to worry for any future receivers in that same session. You can create new sessions and the first receiver for that session with no worries.
Once you want to create a second receiver in a session, if the first receiver has a MessageListener, you have to take care to make sure there are no other threads of execution in that session. You can do this by stopping the connection or actually creating your receiver from the onMessage routine of the first receiver.
29. How do I handle request/response using JMS?
There are several approaches to handling request/response processing with JMS.
* Use a temporary queue for each requestor and have the response go back to that queue.
* Use the QueueRequestor class, which does the temporary queue for you, and wait for the reply, as in the following:
// create temporary queue for receiving answer
qrequestor = new QueueRequestor(qsession, queue);
TextMessage msg = qsession.createTextMessage();
TextMessage reply = (TextMessage) qrequestor.request(msg);
* Use a dedicated response topic or queue with message selectors.
30. How many messages are sent across the network for processing topic messages?
How many messages are sent across the network for processing topic messages?
If there are three subscribers for a message, for example, one of which with a selector that does not match, how many messages are sent?
In WebLogic JMS 6.1, when all three consumers are in the same session, we send one copy of the message across the network for all subscribers that are not flow-controlled. Once a consumer is flow-controlled for not acknowledging enough messages, no messages are sent until flow control is eased. So, the answer is usually one, but may be two. The selection is done on the server side so a subscriber that doesn't match doesn't have to discard anything.
31. Are foreign destinations handled within foreign JMS messages?
WebLogic Server JMS does not know what to do with foreign destinations that it runs into. This issue has been discussed with Sun and the JMS specification does not clearly define destinations well enough for vendors to interoperate at that level. They agree that it is sufficient not to handle foreign destinations preferably in such a way that sending/receiving still work. For WebLogic Server JMS, if you do a setJMSdestination (you should not because it is only for the provider to set it) with a foreign destination, it gets ignored (set to null). Similarly, if you do a setJMSReplyTo for a foreign destination, WebLogic Server JMS will ignore it (set it to null).
32. 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.
33. 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>
34. 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.
a. Home
b. Handle
c. HomeHandle
d. EJBHomeHandle
e. HomeObject
Choice C is correct. Once a client has obtained the EJBHome object for an EJB instance, it can create a reference to the home object by calling getHomeHandle(). getHomeHandle() returns a HomeHandle object, which can be used to obtain the home interface to the same EJB instance at a later time.
A client can pass the HomeHandle object as arguments to another client, and the receiving client can use the handle to obtain a reference to the same EJBHome object. Clients can also serialize the HomeHandle and store it in a file for later use. The HomeHandle interface has only one method getEJBHome(), which returns the EJBHome reference.
