Considering MySQL? Read On... (Part I) @ ECLIPSE DEVELOPER'S JOURNAL

Considering MySQL? Read On... (Part I)

A powerful combination creates a strong architecture

MySQL is a small, fast, and efficient database. This article discusses leveraging MySQL as the database with BEA WebLogic Server 8.1.

We will look at using MySQL as the database engine where the application is developed using BEA WebLogic Workshop 8.1 and deployed to BEA WebLogic Server 8.1. Using an archetypical Java 2 Enterprise Edition (J2EE) architecture, I will evaluate the impact of using MySQL from various aspects such as choosing the correct version of MySQL, setting up the server, and making development adjustments. The impact on development and deployment of bread-and-butter technologies such as Enterprise JavaBeans (EJBs), Java DataBase Connectivity (JDBC), Java Message Service (JMS), and the Java Transaction API (JTA) are evaluated. Various pitfalls are uncovered, logically approached, and methodically solved. The information presented here will not only enhance your understanding of the tools and technologies utilized, but also save you countless hours. Even readers who employ different database technologies will find the information and material practical and useful.

Introduction
The development tool of choice is BEA WebLogic Workshop 8.1. I'll describe an archetypical J2EE architecture and explore the impact of the decision to use MySQL with J2EE technologies such as JDBC and JMS. Part 2 of this series will evaluate the impact of EJBs, the core component model of J2EE as well as the JTA. The article describes configuration and development changes, adjustments, and modifications.

Architecture
The sample application has a standard J2EE architecture consisting of a database tier, an application tier, and an interface tier as depicted in the Figure 1. The database, or back-end, tier consists of MySQL as the Relational DataBase Management System (RDBMS). The application tier is BEA WebLogic Server 8.1. The application server includes a JMS server and an EJB container. The JMS server hosts destinations such as a queue utilized by the sample application for asynchronous processing. The sample application consists of many EJBs that leverage container managed transaction demarcation (CMTD). Tables in the database are mapped to entity EJBs with container-managed persistence (CMP). The entity EJBs are fronted with a session EJB facade. There is a Message-Driven Bean (MDB) that listens to a queue and processes messages. Other applications, such as command-line applications, rich graphical user interface (GUI) applications, or Web applications, leverage the EJB components through the facade. They exchange data with the session facade using value objects (also known as data transfer objects). The value objects corresponding directly to the entity beans are automatically generated by WebLogic Workshop.

Choosing the "Right" MySQL
MySQL comes in various shapes and forms and has at least four different incarnations: MySQL Standard, MySQL Max, MySQL Pro, and MySQL Classic. MySQL Standard and MySQL Pro are identical except for the license. MySQL Standard is licensed under the GNU Public License (GPL), whereas MySQL Pro is a commercially licensed version of MySQL Standard. MySQL Max includes cutting-edge and experimental features and is not recommended for production use. MySQL Classic is available only under commercial license and excludes important features. For this application, support is required for critical features such as transactions and referential-integrity (i.e., foreign key) constraints. The choice of MySQL among its various incarnations is either MySQL Standard or MySQL Pro. Note: Any further reference in this article to MySQL implies usage of MySQL Standard. (More information about the different types of MySQL is available at www.mysql.com/products/mysql/index.html.)

MySQL presents a number of choices for table types, each offering features that have their own pros and cons. The table types are ISAM, MyISAM, HEAP, MERGE, BDB, and InnoDB. Many factors determine the choice of a table type. These factors include, but are not limited to, performance, transactions, row-level locking, and crash recovery. However, the crucial features for the sample application are transactions and referential-integrity constraints.

The InnoDB table type is the only one that meets the criteria. There are at least two ways to specify an InnoDB table type. One is to start the MySQL database server using --default-table-type=InnoDB. A table created with this option is of InnoDB type. (Note: If the default table type of InnoDB is not specified, the default table type is MyISAM.) The other way to specify InnoDB table type is to explicitly mention table type in the Data Description Language (DDL) of the create table script. (More information about MySQL table types is available at www.mysql.com/doc/en/Table_types.html.)

A specific feature about MySQL and foreign constraints is that before the constraint can be created, an index on the column must already exist. For example, consider a one-to-one relationship between the tables Person and Buyer. Buyer has a foreign key to Person. Buyer has a column named Person_Id that is a foreign key to a column named Person_Id in the Person table. But before the foreign key can be established, an index must be created on column Person_Id in the Buyer table. Otherwise, the creation of a foreign key constraint fails. Refer to the sem.sql DDL file in the source code example (the source code is online at www.sys-con.com/ weblogic/sourcec.cfm).

The default database privileges are different for different operating systems. For example, the default privileges on Windows give all local users full privileges without specifying a username or password. Therefore, an important validation is being able to connect to the MySQL database server engine. One way to connect is by using the client program that comes with MySQL. Another way is by using JDBC and a program like DbVisualizer. (See the section "Verify Connectivity using DbVisualizer". Information about default privileges is available at www.mysql.com/doc/en/Default_privileges.html.)

The default case sensitivity of table names is based upon the operating system. For example, on Windows the table names are case insensitive. This is especially important if development is done on one platform but deployment is on another. To avoid such problems, one recommendation is to start the server by setting lower_case_table_names=1 variable. (More information on this variable is available at www.mysql.com/doc/en/Name_case_sensitivity.html.)

Logging is enabled in MySQL by starting the MySQL database server using the --log option. Starting the MySQL server with logging enabled is highly recommended. Logging enables monitoring of Structured Query Language (SQL) statements executed by MySQL and can be a crucial tool in debugging and trouble-shooting issues. (More information on the MySQL log file is available at www.mysql.com/doc/en/Query_log.html.)

The various options, such as default table type and logging, can be specified in a couple of ways. One is to pass the options in as command-line arguments to mysqld, the MySQL database engine executable. The other option is to specify these options in either a my.ini file or my.cnf option file. (More information on option files, including where to place them, is available at www.mysql.com/doc/en/Option_files.html.)

Before we proceed further, complete the following steps:

Download MySQL: www.mysql.com/downloads/mysql-4.0.html.
Install MySQL with these instructions: www.mysql.com/doc/en/Installing.html.
Specify additional options such as logging and table type.
Start MySQL (e.g., using mysqld -- console).
Verify connectivity to the server using mysql (e.g., mysql -p -u root). Note: Just press enter when prompted for a password if local on Windows)
Create a database named semdb using create database semdb.
Use the database semdb using semdb.
Load schema using mysql command source and specifying the fully qualified path to sem.sql (e.g., source c:/MySQL_WLS/db/sem.sql). Note: Use forward slashes even on Windows.
Using the grant.sql file available in the source code, grant privileges using source fully qualified path to grant.sql. Note: Use forward slashes even on Windows.

Downloading the JDBC Driver
JDBC requires a JDBC driver to connect to the database server. Connector/J is the JDBC driver for MySQL. Download and install Connector/J from www.mysql.com/downloads/api-jdbc-stable.html. The download contains a mysql-connector-java-3.0.9-stable-bin.jar file that contains the JDBC drivers.

The following section on verifying the connectivity to MySQL server is optional, but highly recommended.

Verify Connectivity Using DbVisualizer
DbVisualizer ships with BEA WebLogic Platform 8.1. Launch DbVisualizer (e.g., Start Menu > BEA WebLogic Platform 8.1 > Other Development Tools > DbVisualizer on Windows) and add the drivers to DbVisualizer. Using the Connection/J MySQL JDBC driver, connect to MySQL instance (see the section, "Connection to MySQL Database Instance)

Adding JDBC Drivers to DbVisualizer
The following steps describe adding the drivers to DbVisualizer.

Select Database Menu.
Select DriverManager Menu item.
Select Add new driver location toolbar menu item.
Select mysql-connector-java-3.0.9-stable-bin.jar.
Close.

Connection to MySQL Database Instance
The following steps describe connecting to the MySQL database instance.

Select Database Menu.
Select Add Database Connection Menu Item.
Specify Connection Alias (e.g., sem).
Choose JDBC Driver as com.mysql.jdbc.Driver from the dropdown list.
Choose Database URL as jdbc:mysql://<host>/<database> from the drop-down list.
Change <host> (e.g. localhost).
Change <database> to semdb.
Specify Userid as sem.
Specify Password as sem.
Select Connect.

WebLogic Domain Configuration Changes
The BEA WebLogic Domain Configuration Wizard is used to create WebLogic Server domains. A particular type of domain is created based on functionality required. For this particular application, create a WebLogic Workshop domain. For example, create a WebLogic Workshop domain named SEMDomain.

In order to use JDBC with BEA WebLogic Server, WebLogic Server needs to know about the JDBC driver. The JDBC driver needs to be in the CLASSPATH so that the server can locate the driver. For the SEMDomain, add the JDBC driver to the CLASSPATH so that the WebLogic Server can find the JDBC driver.

Add JDBC Driver To The CLASSPATH
The following steps describe adding the Connector/J MySQL JDBC driver to the CLASSPATH.

Edit .../SEMDomain/_cfgwiz_donotdelete/startscript.xml.
Add mysql-connector-java-3.0.9-stable-bin.jar to the CLASSPATH. Refer tothe startscript.xml file in the source code.
Add system property Dweblogic.ejb20.cmp.rdbms.codegen.verbose=true as JAVA_OPTIONS. Refer to the startscript.xml file in the source code.
Run the Configuration Wizard to extend the SEMDomain.
Select DefaultWebApp as the extension.
Finish the Configuration Wizard.

The following section on enabling more WebLogic Server logging is optional, but highly recommended.

WebLogic Logging
By default, BEA WebLogic Server performs only limited logging. During development, logging and observing of more information is very useful. For the SEMDomain, change the logging level to Info.

Changing the Logging Level
The following steps describe changing the BEA WebLogic Server logging configuration.

Make sure BEA WebLogic Server is running.
Launch the WebLogic Server Console.
Log into the Console.
Select Servers/cgServer.
Select Logging tab.
Check Debug to Stdout checkbox.
Select Stdout Severity Threshold as Info from the drop-down list.

JMS Domain Configuration Changes
By default, a newly created domain like the SEMDomain uses PointBase as the database. A connection pool named cgPool connects to PointBase and a corresponding datasource named cgDataSource. The JMS server uses the cgDataSource as the persistence store. To use another database, such as Oracle, just change the configuration of the connection pool. The JMS server then uses Oracle as the persistence store. However, simply changing the connection pool to MySQL does not work, because when the WebLogic server boots-up, the JMS server complains that MySQL is not a supported database. A practical alternative is to change from using a database as the persistence store to using a file as the persistence store. WebLogic JMS supports a persistence file store. For the SEMDomain, change the persistence store to a file store.

Changing the File Store
The following steps describe configuring the file store:

Create a directory where the file store is going to be placed.
Make sure BEA WebLogic Server is running.
Launch the WebLogic Server Console.
Log into the console.
Select Services/JMS/Stores in the left navigation pane.
Select Configure a new JMS File Store.
Specify Name (e.g., cgJMSFileStore).
Specify Directory that was created in the earlier step.
Select Services/JMS/Servers/cgJMSServer.
Change the Persistence Store (to, for example, cgJMSFileStore) by selecting it from the drop-down list.

The bottom line is that MySQL cannot be used as a persistence store for JMS. Using a file persistence store is a viable alternative. Keep this in mind when creating other JMS servers.

In order to follow the source code example, complete an additional JMS configuration for the sample application before proceeding further:

Set up a JMS file store named semJMSFileStore.
Set up a JMS connection factory named semJMSConnectionFactory with jms/semJMSConnectionFactory as the JNDI name.
Set up a JMS server named semJMSServer with semJMSFileStore as the persistent store.
Set up a distributed destination named PersonQueue with jms/PersonQueue as the JNDI name.
Deploy the PersonQueue on the semJMSServer.

JDBC Domain Configuration Changes
To utilize the JDBC API in the BEA WebLogic Server applications, create and deploy a connection pool and a datasource. First, create the connection pool, then create the datasource on top of the connection pool.

Before proceeding further, complete the JDBC configuration for the sample application. Set up the following:

Connection pool: Refer to "Configuring the Connection Pool" for detailed instructions.

Datasource: Use jdbc/semJDBCDataSource as the JNDI name. Refer to "Configuring the Datasource" for detailed instructions.

Configuring the Connection Pool
The following steps describe configuration of the connection pool.

Make sure BEA WebLogic Server is running.
Launch the WebLogic Server Console.
Log into the console.
Select Services/JDBC/Connection Pools.
Select Configure a New JDBC Connection Pool.
Select MySQL from the Database Type drop down list.
Select MySQL's Driver (Type 4) Version: Any from Database Driver.
Specify Name (e.g., semJDBCConnectionPool).
Specify Database Name (e.g., semdb).
Specify Host Name (e.g., localhost).
Specify Username (e.g., sem).
Specify Password (e.g., sem).
Test the driver configuration.
Create and deploy.

Configuring the Datasource
The following steps describe configuration of the datasource:

Select Services/JDBC/Data Sources.
Select Configure a New JDBC Data Source.
Specify Name (e.g. semJDBCDataSource).
Specify JNDI Name (e.g., jdbc/semJDBCDataSource).
Select Continue.
Specify Pool Name (e.g., semJDBCConnectionPool).
Target the datasource by clicking on Create.

Conclusion
This article discussed how to select the "right" version of MySQL and described various changes to the BEA WebLogic Domain Configuration to support key J2EE technologies such as JDBC and the Java Message Service. My next article will explore advanced topics such as EJBs and JTA.

Understanding the impact of leveraging MySQL on technologies such as JDBC and JMS is crucial to successful project implementation. As illustrated here, MySQL, BEA WebLogic Workshop, and BEA WebLogic Server form a powerful combination to architect, design, and deploy real-world applications.

I want to thank Steve Ditlinger, Roshni Malani, and Sarah Woo for reviewing this article and providing invaluable feedback.

References

To discuss the article and ask questions: http://groups.yahoo.com/group/bartssandbox. Free membership enrollment is required.

Main MySQL Web site: www.mysql.com

Starting point for MySQL documentation: www.mysql.com/documentation/index.html

www.oreillynet.com/lpt/wlg/3946

DuBois, Paul (2003). MySQL: The Definitive Guide to Using, Programming, and Administering MySQL 4 databases. Sams. An excellent reference. (www.bookpool.com/.x/d4jha9om4m/sm/0735712123).

J2EE patterns: http://java.sun.com/blueprints/patterns/index.html). For the Session Facade Pattern used in the sample application refer to http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html and http://java.sun.com/blueprints/patterns/SessionFacade.html. For the Value Object Pattern used in the sample application refer to http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html and http://java.sun.com/blueprints/patterns/TransferObject.html

Related Links

▪ Source Code (zip file)

About Prakash Malani
Prakash Malani has extensive experience in architecting, designing, and developing object-oriented software and has done software development in many application domains such as entertainment, retail, medicine, communications, and interactive television.He practices and mentors leading technologies such as J2EE, UML, and XML. Prakash has published various articles in industry- leading publications.