Predesign: Containers and Databases
Before you begin designing your application, it is essential that you consider the execution environment in which your code is run. The execution environment includes the following specifics regarding your system:
- Hardware platform
- Operating system
- Java Virtual Machine (JVM) implementation
- Application server (EJB container and persistence provider)
- Database server
Each of these elements has a direct effect on your application design's success. We won't talk about hardware and operating systems (about which you may have little choice anyway), and we'll stay away from arguments about who has a better JVM.
Instead, we'll focus on the last two issues; they have the greatest effect on EJB application architecture.
Container Capabilities
Which EJB container you choose has a significant effect on your application's implementation and design. Regardless of your application's functional requirements, spend some time familiarizing yourself with how your application server works. Ideally, you'd develop that familiarity before choosing your application server.
When learning your container's capabilities,
you are trying to find out how the application server's vendor has implemented its key features. Here are the primary areas on which to focus:
What vendor-specific functionality or extensions does it implement? -
Almost all EJB containers introduce some vendor-specific features. If you choose to use them, your application will be tied to that vendor's container. Switching to another vendor later may be costly. While this is often unavoidable (several popular development tools, for example, tie you closely to a vendor's implementation), there are tools out there that help to alleviate some of the risk.
How does the container's design or implementation affect performance? -
Because every vendor's implementation of the EJB spec is unique, containers from different vendors will perform differently. If possible, research the performance of your various container options for the specific functionality you need before choosing.
Can the container scale in a clustered environment? -
As your business ramps up, you may find that you need to add additional hardware to meet the load and demands of your new business. Does your vendor work well in a clustered environment of networked computers? Does it provide load balancing, failover, and replication of critical data? Ask your vendor these questions before you make your decision.
How much is this going to cost me? -
Open source application servers are starting to commoditize and dominate the application server market. They compete head-to-head in functionality, stability, and scalability with their commercial counterparts. Why pay for empty software licenses when you can get the same features for free? The JBoss workbook at the end of this book is one example of an open source solution, but you should check out Glassfish, JOnAS, and Apache Geronimo as well.
Most vendors do a good job of implementing the specification, and it's relatively easy to move from one vendor to another. But don't walk into the EJB arena with your
eyes closed. Ask the same kinds of questions that you would ask before making any other major software purchase, and you'll be OK.
Database Capabilities
While we place a lot of emphasis on the EJB container and persistence provider, the database server is just as influential on the overall system. Although the EJB container and Java Persistence isolate you from the database, the database is still there, and every data-related function depends on it.
The most critical function of a database is to ensure that data is available and consistent. Availability and consistency are qualities that depend on how your application uses transactions and how the database implements transactions. When investigating how your database implements transactions, your primary concern should be the database's locking, isolation levels, and other resource management issues. Here are some questions to ask:
What transaction isolation levels does the database support? -
Although most databases support the four isolation levels discussed in Chapter 16 (Read Uncommitted, Read Committed, Repeatable Read, and Serializable), some do not. For example, PostgreSQL 7.3.x offers only Read Committed and Serializable.
What are the lock types and lock scopes? What factors influence them? -
Lock scope is the number of rows that are protected when a lock is enacted. Depending on the vendor, the database may lock only the rows used by the transaction, blocks of rows (pages) that contain the rows used, or the entire table. The more rows are protected, the more likely it is that another process won't be able to access the data it needs. If such contention occurs, the other process will either fail or wait until the lock is released.
As for what factors influence lock types and lock scopes, the database may "promote" locks under certain situations, such as when a query cannot use an index. This could mean that a nonexclusive write lock becomes an exclusive write lock or that a row-specific lock becomes a table-wide lock, should an index on that table not be usable in the write.
How are database resources handled within a transaction? -
During a transaction, especially a multistep transaction, the database has certain resources that it must manage. A good example is the number of open cursors involved in executing the transaction. Depending on how the database handles reclaiming those open cursors, a series of database operations that work fine outside of a transaction may not work at all when included in one because needed
cursors are left committed until after the last operation. In this case, large, multistep, iterative processes ("batch" processes) can hit the maximum number of open cursors and fail. Knowing how your database manages resources such as open cursors can help you plan your transaction structure to ensure success.
Obviously, more is involved in the selection of a database server for your application/system than we've described here. However, all of these issues have direct ramifications on your EJB application.
 |
]