We're nearly done covering the topics for the test. This month I'll discuss JDBC, transactions, and clustering. Be sure to give careful attention to these topics, as they can slip by during studying. As in my previous articles, I've included a sample test to help you study for the real test. Let's get started with JDBC.

JDBC Now, I'm sure most BEA WebLogic Developer's Journal readers have a good amount of JDBC experience, so I'll only touch on the WLS-specific aspects of JDBC you'll need to know to pass the test.

First, a word about transaction isolation levels. The isolation level of a connection determines how database transactions are protected from one another. Transaction isolation is a database concept enforced at the database software level. WebLogic supports a series of common transaction isolation levels. These are passed to the proper resource manager, where the database software will handle enforcing them. Note that not all databases support transaction isolation.

A connection pool is a group of JDBC connections to a database. Using connection pools provides a significant performance advantage to your application. Connection pools can be configured either statically at application startup or dynamically within a Java application. You can obtain a pool object from "weblogic.jdbc.JdbcServices," using a JNDI lookup. Be sure to review Table 1, which lists some connection pool methods of note.

WebLogic has a way to access multiple connection pool objects, a feature called MultiPools. A MultiPool is a useful mechanism to provide load balancing and high-availability services. To gain the load-balancing and high-availability functionality of MultiPools, your databases must support real-time replication. MultiPools are configured statically, using the Administrative Console. In WLS 6.0, there is no way to dynamically configure MultiPools.

MultiPools are load balanced by using the Round-Robin algorithm, which chooses in order from the list of connection pools. MultiPools provide high-availability services if the database connectivity has been lost. A new connection is attempted with the next pool in the connection pool list. Please note that the high-availability services aren't a fail-safe mechanism - MultiPools will only fail over for a new connection. Any existing connection that fails, for any reason, will return an exception to the application - the MultiPool won't attempt to reconnect on behalf of an existing client. Another important note: MultiPools only fail over when database connectivity is lost, or when the database is dead. Capacity or other exceptions will not cause failover because these could be set on a per-connection basis.

Transactions
In order to coordinate distributed transactions, WLS 6.0 supports Extended Architecture (XA), which defines the protocol used for different resource managers to communicate with one another. By using XA, the server implements the two-phase commit protocol to support distributed transactions. Transactions may span EJB accesses, JDBC connections, and JMS connections. In order to use this feature, the resource manager must be XA-compliant.

Let me point out that the two-phase commit protocol guarantees data integrity by ensuring that a transaction is either updated by all of the databases in a distributed transaction, or by none of them. The first phase of a two-phase commit is the prepare phase, in which all the resources vote on whether or not to commit the transaction. If all the resources participating in the transaction vote to commit, the updates are made to all the databases during the second phase. If any one of the databases votes to roll back, then the transaction is rolled back for all of the participating databases.

In handling transactions for EJBs, WLS 6.0 offers two different types of transaction schemes. You may choose to define your EJBs as using either container-managed or bean-managed transactions. Using container-managed transactions indicates the container will manage the transactional demarcation of the bean. In contrast, bean-managed transactions leave it up to the bean developer to indicate the transactional demarcation.

For container-managed transactions, the transaction attribute is supplied to the container by the ejb-jar.xml file. The "trans-attribute" deployment descriptor defines how the container will deal with transactions. The list of transactional attributes is shown in Table 2.

Container-managed transactions may be specified for session beans and message-driven beans, but must be used for entity beans. Because a message-driven bean has no client, message-driven beans that use container-managed transactions must be deployed using either the Required or NotSupported transaction attribute.

In message-driven beans, a new transaction is started for every message. The transaction is committed automatically at the end of the onMessage method, unless setRollbackOnly() is called.

For bean-managed transactions, however, since the bean is in charge of managing its own transactions, it must be able to indicate when a transaction has started or ended. The container provides the UserTransaction object to allow the bean to demarcate the transaction boundaries.

The UserTransaction object is obtained through the bean context's getUserTransaction() method. In addition, the container must expose the UserTransaction through JNDI and can be accessed using the java:comp/UserTransaction name. Table 3 lists the UserTransaction methods you should know for the test.

As stated before, a client may start a transaction by obtaining the UserTransaction object through JNDI. After the transaction is started, any EJB methods or JDBC/JMS connections will be included in the transaction, provided the resource managers are all XA-compliant.

Clustering
Believe it or not, WLS 6.0 clustering functionality gets a good amount of coverage on the test. For review, a cluster is a group of WebLogic servers acting as a single server for the purposes of scalability and high availability. Although the cluster appears to be a single server from the perspective of the application, it's necessary for the developer and administrator to understand the behavior of WLS clusters.

In order to provide adequate scalability, WLS supports four algorithms for load balancing objects in a cluster. The algorithms determine how the server will achieve scalability by distributing the load across the cluster. Each algorithm has its advantages and disadvantages. The algorithms are listed in Table 4. Be sure to note that the default algorithm for object clustering is Round Robin.

High Availability
As for providing high availability, WLS 6.0 provides some services to ensure that your EJBs are available. WLS employs something known as a replica-aware stub. When an EJB is called through the replica-aware stub, if a failure occurs, the stub intercepts the exception and retries the call on another replica.

Given that, WLS 6.0 handles failover scenarios differently for differing types of services. Before we get into the details, you should know the term idempotent. If a bean is marked as idempotent, it means that it can be restarted without any side effects - the result will be the same. In this case, the server will actually retry a method that fails during the request, because it can just retry the method call on another server and assume the result will be the same.

Now, in the case of nonidempotent objects, WLS 6.0 will still attempt to keep your objects available by failing over if the method hasn't actually been called (to be specific, if the ConnectException or MarshalException is thrown).

For stateless session beans, if a bean isn't available on one server, WLS will try to use the same bean on all other servers in the cluster. As for a stateless session bean, if the bean isn't available, WLS will try the one backup server. Calls to stateful session beans are "pinned" to the server in the cluster, since state is being maintained. The stateful session bean is replicated to the backup server after a transaction is committed or at the end of a method call.

The good news is that there isn't much left to discuss about the test. Next month I'll cover the one major topic left: administration. This will include discussions on deployment, security, and server usage. In addition, I'll touch on a few things that don't really fit into any category I've discussed before. I'll also include a slightly larger sample test that will encompass all of the topics we've covered so far.

That's it for this month! Have fun taking the sample test below. Good luck!

Sample Test
1.   Which class would be the most efficient to use to perform multiple SQL INSERT statements into a database?
a) Statement
b) CompiledStatement
c) CallableStatement
d) PreparedStatement

2.   Which statement about transaction isolation is true?
a) WLS 6.0 implements transaction isolation support.
b) The database software is responsible for implementing transaction isolation.
c) Changing the transaction isolation levels will segment the database.
d) None of the above.

3.   Which method of the Pool interface allows you to reduce the number of database connections used after a peak usage period?
a) ShutdownSoft
b) Shrink
c) Reset
d) DisableDroppingUsers

4.   At which point does a MultiPool implement the failover algorithm?
a) When database capacity is reached
b) When a database-related exception is thrown
c) When the database is dead
d) All of the above

5.   Which statement about MultiPools is true?
a) MultiPools may be dynamically configured.
b) MultiPools provide real-time replication services to any database system.
c) MultiPools must be configured using the same JDBC driver for all connection pools.
d) None of the above.

6.   What interface do you use when demarcating a bean-managed transaction?
a) UserTransaction
b) Transaction
c) TxHelper
d) StartTransaction

7.   How can you prevent a transaction from committing when using container-managed transaction demarcation?
a) Use the rollback() method.
b) Use the getRollbackReason() method.
c) Use the setRollbackOnly() method.
d) You can't prevent a transaction from committing when using container-managed transactions.

8.   If a transaction is rolled back, what interface must you implement so a session bean receives notification of the rollback?
a) SessionSynchronization
b) UserTransaction
c) Transaction
d) All of the above

9.   What load-balancing algorithm has the problem of convoying?
a) Round Robin
b) Random
c) Weighted Round Robin
d) Parameter-Based

10.   Which load-balancing algorithm uses the CallRouter interface?
a) Round Robin
b) Random
c) Weighted Round Robin
d) Parameter-Based.

1. d, 2. b, 3. b, 4. c, 5. d, 6. a, 7. c, 8. a, 9. a, 10. D