Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 126 127 128 129 130 131 < 132 > 133 134 135 136 137 138 .. 166 >> Next

ASSESSMENT: May work great, but at what cost?
Database Autogeneration Approaches
As the designers of the video store solution research new approaches, they decide to use the autogeneration facilities that their chosen database vendor provides. The database vendor supports a counter for the primary key that is incremented every time a new record is created. This is powerful because it provides a centralized mechanism for generating primary keys, guaranteeing uniqueness. In the solution, the VideoUser entity bean manages its own persistence. A potential problem here is the nonportability of this solution. If there is a need to switch to another database vendor that does not support autogeneration, the application will be in trouble. Luckily, many database vendors do support autogeneration, so developers may consider this to be a minor concern.
364 Item 42
Of the approaches we've discussed so far, this seems to have the most merit. In the past, it has been difficult to make SQL calls to get autogenerated IDs in a nonproprietary way. It was also a challenge to get the autogenerated key right after the insert, because there was not a way to retrieve the generated key from the resulting Result-Set. Luckily, with the release of JDK 1.4, an inserted row can return the generated key using the getGeneratedKeys() method in java.sql.Statement, as can be seen in the code segment below.
int primkey = 0;
Statement s = conn.prepareStatement();
s.execute("INSERT INTO VIDEOUSERS" +
"(name,phone,address,creditcard)" +
"VALUES ('Matt Van Wie', '555-9509', '91 Habib Ave', '208220902033XXXX')",
Statement.RETURN_GENERATED_KEYS);
ResultSet rs = s.getGeneratedKeys();
if (rs.next())
{
primkey = rs.getInt(1);
}
Many developers using an earlier version of the JDK (or JDBC 2.0 or earlier drivers) that cannot take advantage of this feature use stored procedures in SQL that can be called from Java with the CallableStatement interface. The "Stored Procedures for Autogenerated Keys" EJB Design Pattern from Floyd Marinescu's book, EJB Design Patterns, provides such a solution that does an insert and returns the autogenerated key.4
ASSESSMENT: This is a good solution. With the release of JDK 1.4 and the ability to get generated keys returned from the java.sql.Statement interface, this provides a sound mechanism for solving the EJB primary key problem.
Other Approaches
It is important to note that EJB Design Patterns (Marinescu, 2002), discussed in the previous section, provides a few design patterns to solve this problem. One worth mentioning is a Universally Unique Identifier (UUID) pattern for EJB, which is a database-independent server-side algorithm for generating primary keys. Another pattern, called Sequence Blocks, creates primary keys with fewer database accesses, using a combination of an entity bean that serves as a counter and a stateless session bean that caches many primary keys from the entity bean at a time.
4 Marinescu, Floyd. EJB Design Patterns. John Wiley & Sons, 2002.
The Stateful Stateless Session Bean 365
ASSESSMENT: These are good design patterns for solving the problem and are described in detail in the book. You can also check out discussions on this topic at http://www.theserverside .com/.
There are many traps that a J2EE architect can fall into when attempting to generate unique identifiers for primary keys. There are also many approaches to solving this problem. This pitfall showed several approaches and provided assessments for each. By avoiding some of the traps discussed in this pitfall item, you will save yourself time and headaches.
Item 43: The Stateful Stateless Session Bean
A developer approached me the other day with an interesting problem. He had an existing API that he wanted to use (in a bean) that builds an index once and then provides search access to it. It seems a pretty simple idea in objected-oriented parlance. There is an object with a member variable, the index, which is built at initialization, and then methods that provide access to it (in this case, search). Figure 43.1 is a simplified example of what the class would look like.
There was concern about how to build this. This developer had some experience with EJB and understood the basic concepts. There are three types of Enterprise Java Beans: session beans, entity beans, and message-driven beans. In addition, there are two flavors of session beans: stateful and stateless. The idea is that stateful session beans maintain their state across invocations, and stateless session beans do not. Entity beans provide real-time persistence of business objects.
The developer had developed EJBs prior to this, but his work had been confined to new development—that is, from whole cloth—and dealt with basic problems. This was the first time where he was trying to use something else in the EJB paradigm.
To examine this dilemma, we reviewed the different options.
Index
J] theIndex : Index
search(searchString : String) : ArrayList initialize()
Previous << 1 .. 126 127 128 129 130 131 < 132 > 133 134 135 136 137 138 .. 166 >> Next