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 .. 124 125 126 127 128 129 < 130 > 131 132 133 134 135 136 .. 166 >> Next

18 }
19 while (rs.next())
20 {
21 String table = rs.getString("TABLE_NAME");
22 ll.add(table);
23 System.out.println("ResultSet 1: Got table " + table);
24
25 }
26 rs.close();
27
28 Listlterator li = ll.listIterator(0);
29
Listing 41.4 A better printMetaDataStuff() method
Generating Primary Keys for EJB 359
30 while (li.hasNext())
31 {
32 String table = li.next().toString();
33 ResultSet rs2 = dmd.getColumns(null,null,table,null);
34
35 if (rs2 == null)
36 {
37 throw new Exception ("No Metadata!”);
38 }
39 while (rs2.next())
40 {
41 String col = rs2.getString("COLUMN_NAME”);
42 System.out.println("ResultSet2: Table " + table +
43 " has column " + col);
44 }
45 rs2.close();
46 }
47 }
Listing 41.4 (continued)
After you replace your printMetaDataStuff() method, you run the same script shown in Listing 41.2. Now your connection to each database prints out all tables and columns without any errors, and you are ready to create your query builder application.
This pitfall showed how important it is to be aware of the problem of using more than one ResultSet at once. While many JDBC drivers will support the use of multiple concurrent ResultSet objects, many will not. Many databases will exceed the number of maximum open cursors. To achieve maximum portability, rethink your designs so that you will only have one open at a time.
Item 42: Generating Primary Keys for EJB
In a distributed environment, it is imperative to be able to distinguish different instances of objects. With the distributed model of Enterprise JavaBeans, it is important to be able to distinguish instances of entity beans from each other. A common trap that many EJB developers fall into relates to the methods of generating primary keys for entity beans. This item provides an example scenario, gives several examples of how an EJB developer could fall into such a trap, and provides solutions to the problem.
A Simple Scenario
A large video store chain wants to provide national access to accounts throughout the United States. When a customer brings her identity card to the store, the store would like to look up account information and allow the customer to check out videos—no
360 Item 42
matter where the customer started the account. It was decided early on that the J2EE model would provide a flexible solution for this video chain. In a high-level design phase, they decided that their JSP would eventually talk to a session bean called SignOnVideoBean, which would create an entity bean called VideoUser, as shown in Figure 42.1. The question is this: How should the primary key for VideoUser be created? We will look at many approaches and discuss pitfalls that lie in each solution.
A "Client Control" Approach
In many small systems, it is commonplace to have the client application (or sometimes the user) generate a unique identifier that represents a new user. An example of this could be an application where a user chooses a user identifier (userid) for access into a portal. In these types of applications, a servlet or JSP from the Web tier initiates a transaction that eventually triggers the creation of an entity bean, which uses the passed-in user identifier as its primary key. This is a valid practice, and depending on the backend database constraints for primary keys, strings that are guaranteed to be unique (such as email addresses) can be used as the unique identifiers. If there is a collision, the EJB will throw a javax.ejb.CreateException. The difficulty is finding a recipe for the creation of these primary keys—throwing and passing exceptions over a network can be bandwidth costly and pretty annoying.
To prevent primary key collisions, they chose a recipe for creating a primary key in such a way that the date, time, store number, clerk ID, and customer name compose the primary key. For example, if "Matt Van Wie" were to start an account at the second Mechanicsville, Virginia, branch of the video store on March 1, 2003, at 5:30 p.m., and the clerk was "Todd Tarkington," the primary key would be "MattVanWie-03-01-2003-530pm-MechanicsvilleVA2-ToddTarkington". This approach is shown in Figure 42.2.
Figure 42.1 Creating video user accounts.
Generating Primary Keys for EJB 361
Figure 42.2 Client control solution.
In Figure 42.2, the client application passes the system date, time, store number, clerk identifier, clerk ID, and client name to the servlet/jsp, which creates the unique identifier and creates a reference to SignOnVideoBean, which is the session bean that is used to access customer information and create users. SignOnVideoBean creates a VideoUser entity bean, which is the entity bean that represents the video store customer. This particular approach has many problems that could lead to collisions and chaos:
¦¦ For owner names and clerk names that are commonplace, such as "Steve Jones" and "Kevin Smith," there is potential for primary key collisions.
Previous << 1 .. 124 125 126 127 128 129 < 130 > 131 132 133 134 135 136 .. 166 >> Next