[ Pobierz całość w formacie PDF ]
declarations would be {0.email} and {0.cell.areaCode} but not {0.cell}. The JDBC type
Page 41
C H A P T E R 5 : QU E R I E S P A G E 4 2
used to set a parameter is based on the class type of the property and the datasource-
mapping of the entity. The JDBC type used to set the parameter is the JDBC type that is
declared for that property in the dependent-value-class element.
An entity parameter can be any entity in the application. An entity parameter must be
dereferenced down to a simple primary key field or simple property of a DVC primary key
field. For example, if we had a parameter of type Gangster, a valid parameter declaration
would be {0.gangsterId}. If we had some entity with a primary key field named info of
type ContactInfo (as declared in Chapter 3), a valid parameter declaration would be
{0.info.cell.areaCode}. Only fields that are members of the primary key of the entity can
be dereferenced (this restriction may be removed in later versions). The JDBC type used
to set the parameter is the JDBC type that is declared for that field in the entity
declaration.
BMP Custom Finders
JBossCMP continues the tradition of JAWS in supporting bean managed persistence custom
finders. If a custom finder matches a finder declared in the home or local home interface,
JBossCMP will always call the custom finder over any other implementation declared in the
ejb-jar.xml or jbosscmp-jdbc.xml files. The following simple example finds the entities by a
collection of primary keys: 15
public abstract class GangsterBean implements EntityBean {
public Collection ejbFindByPrimaryKeys(Collection keys) {
return keys;
}
}
Listing 5-16, Custom Finder Example Code
15
This is a very useful finder because it quickly coverts primary keys into real Entity objects without contacting the database. One drawback
is that it can create an Entity object with a primary key that does not exist in the database. If any method is invoked on the bad Entity, a
NoSuchEntityException will be thrown.
Page 42
Chapter
6
6. Optimized Loading
The goal of optimized loading is to load the smallest amount of data required to complete a
transaction in the least number of queries. The tuning of JBossCMP depends on a detailed
knowledge of the loading process. This chapter describes the internals of the JBossCMP loading
process and its configuration. Tuning of the loading process really requires a holistic
understanding of the loading system, so this chapter may have to be read more than once.
Loading Scenario
The easiest way to investigate the loading process is to look at a usage scenario. The most
common scenario is to locate a collection of entities and iterate over the results performing some
operation. The following example generates an html table containing all of the gangsters:
public String createGangsterHtmlTable_none() throws FinderException {
StringBuffer table = new StringBuffer();
table.append("");
Collection gangsters = gangsterHome.findAll_none();
for(Iterator iter = gangsters.iterator(); iter.hasNext(); ) {
Gangster gangster = (Gangster)iter.next();
table.append("");
table.append("").append(gangster.getName()).append("");
table.append("").append(gangster.getNickName()).append("");
table.append("").append(gangster.getBadness()).append("");
table.append("");
}
table.append("");
return table.toString();
}
Listing 6-1, Loading Scenario Example Code
Assume this code is called within a single transaction and all optimized loading has been disabled.
At Arrow 1, JBossCMP will execute the following query:
SELECT t0_g.id
FROM gangster t0_g
Page 43
C H A P T E R 6 : OP T I MI Z E D L OA D I NG P A G E 4 4
ORDER BY t0_g.id ASC
Listing 6-2, Unoptimized findAll Query
Then at Arrow 2, in order to load the eight Gangsters in the sample database, JBossCMP
executes the following eight queries:
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=0)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=1)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=2)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=3)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=4)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=5)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=6)
SELECT name, nick_name, badness, hangout, organization
FROM gangster WHERE (id=7)
Listing 6-3, Unoptimized Load Queries
There are two problems with this scenario. First, an excessive number of queries are executed
because JBossCMP executes one query for findAll and one query for each element found; this is
called the "n+1" problem16 and is addressed with the read-ahead strategies described in the
following sections. Second, values of unused fields are loaded because JBossCMP loads the
16
The reason for this behavior has to do with the handling of query results inside the JBoss container. Although it appears that the actual
entity beans selected are returned when a query is executed, JBoss really only returns the primary keys of the matching entities, and does not
load the entity until a method is invoked on it.
Page 44
C H A P T E R 6 : OP T I MI Z E D L OA D I NG P A G E 4 5
hangout and organization fields, 17 which are never accessed. Configuration of eager loading is
described in the Eager-loading Process section of this chapter. The following table shows the
execution of the queries:
Table 6-1, Unoptimized Query Execution
id name nick_name badness hangout organization
0 Yojimbo Bodyguard 7 0 Yakuza
1 Takeshi Master 10 1 Yakuza
2 Yuriko Four finger 4 2 Yakuza
3 Chow Killer 9 3 Triads
4 Shogi Lightning 8 4 Triads
5 Valentino Pizza-Face 4 5 Mafia
6 Toni Toothless 2 6 Mafia
7 Corleone Godfather 6 7 Mafia
Load Groups
The configuration and optimization of the loading system begins with the declaration of named
load groups in the entity. A load group contains the names of cmp-fields and cmr-fields with a
foreign key (e.g., Gangster in the Organization-Gangster example) that will be loaded in a single
operation. An example configuration follows:
GangsterEJB
basic
name
nickName
badness
17
Normally JBossCMP would also load the contactInfo field, but for the sake of readability, it has been disabled in this example because
contact info maps to seven columns. The actual configuration used to disable the default loading of the contactInfo field is presented in
Listing 6-12.
Page 45
C H A P T E R 6 : OP T I MI Z E D L OA D I NG P A G E 4 6
contact info
nickName
contactInfo
[ Pobierz całość w formacie PDF ]
zanotowane.pldoc.pisz.plpdf.pisz.plalternate.pev.pl
|
|
|
