Este contenido no está disponible en el idioma seleccionado.
31.7.3. Read-ahead
Optimized loading in JBoss is called read-ahead. This refers to the technique of reading the row for an entity being loaded, as well as the next several rows; hence the term read-ahead. JBoss implements two main strategies (on-find and on-load) to optimize the loading problem identified in the previous section. The extra data loaded during read-ahead is not immediately associated with an entity object in memory, as entities are not materialized in JBoss until actually accessed. Instead, it is stored in the preload cache where it remains until it is loaded into an entity or the end of the transaction occurs. The following sections describe the read-ahead strategies.
The on-find strategy reads additional columns when the query is invoked. If the query is on-find optimized, JBoss will execute the following query when the query is executed.
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
SELECT t0_g.id, t0_g.name, t0_g.nick_name, t0_g.badness
FROM gangster t0_g
ORDER BY t0_g.id ASC
Copy to ClipboardCopied!Toggle word wrapToggle overflow
All of the required data would be in the preload cache, so no additional queries would need to be executed while iterating through the query results. This strategy is effective for queries that return a small amount of data, but it becomes very inefficient when trying to load a large result set into memory. The following table shows the execution of this query:
Expand
Table 31.2. on-find Optimized 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
The read-ahead strategy and load-group for a query is defined in the query element. If a read-ahead strategy is not declared in the query element, the strategy declared in the entity element or defaults element is used. The on-find configuration follows:
<jbosscmp-jdbc>
<enterprise-beans>
<entity>
<ejb-name>GangsterEJB</ejb-name>
<!--...-->
<query>
<query-method>
<method-name>findAll_onfind</method-name>
<method-params/>
</query-method>
<jboss-ql><![CDATA[
SELECT OBJECT(g)
FROM gangster g
ORDER BY g.gangsterId
]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
</read-ahead>
</query>
</entity>
</enterprise-beans>
</jbosscmp-jdbc>
<jbosscmp-jdbc>
<enterprise-beans>
<entity>
<ejb-name>GangsterEJB</ejb-name>
<!--...-->
<query>
<query-method>
<method-name>findAll_onfind</method-name>
<method-params/>
</query-method>
<jboss-ql><![CDATA[
SELECT OBJECT(g)
FROM gangster g
ORDER BY g.gangsterId
]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
</read-ahead>
</query>
</entity>
</enterprise-beans>
</jbosscmp-jdbc>
Copy to ClipboardCopied!Toggle word wrapToggle overflow
One problem with the on-find strategy is that it must load additional data for every entity selected. Commonly in web applications only a fixed number of results are rendered on a page. Since the preloaded data is only valid for the length of the transaction, and a transaction is limited to a single web HTTP hit, most of the preloaded data is not used. The on-load strategy discussed in the next section does not suffer from this problem.
Left join read ahead is an enhanced on-findread-ahead strategy. It allows you to preload in one SQL query not only fields from the base instance but also related instances which can be reached from the base instance by CMR navigation. There are no limitation for the depth of CMR navigations. There are also no limitations for cardinality of CMR fields used in navigation and relationship type mapping, i.e. both foreign key and relation-table mapping styles are supported. Let us look at some examples. Entity and relationship declarations can be found below.
Suppose we have an entity D. A typical SQL query generated for the findByPrimaryKey would look like this:
SELECT t0_D.id, t0_D.name FROM D t0_D WHERE t0_D.id=?
SELECT t0_D.id, t0_D.name FROM D t0_D WHERE t0_D.id=?
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Suppose that while executing findByPrimaryKey we also want to preload two collection-valued CMR fields bs and cs.
<query>
<query-method>
<method-name>findByPrimaryKey</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM D AS o WHERE o.id = ?1]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="bs" eager-load-group="basic"/>
<left-join cmr-field="cs" eager-load-group="basic"/>
</read-ahead>
</query>
<query>
<query-method>
<method-name>findByPrimaryKey</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM D AS o WHERE o.id = ?1]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="bs" eager-load-group="basic"/>
<left-join cmr-field="cs" eager-load-group="basic"/>
</read-ahead>
</query>
Copy to ClipboardCopied!Toggle word wrapToggle overflow
The left-join declares the relations to be eager loaded. The generated SQL would look like this:
SELECT t0_D.id, t0_D.name,
t1_D_bs.id, t1_D_bs.name,
t2_D_cs.id, t2_D_cs.name
FROM D t0_D
LEFT OUTER JOIN B t1_D_bs ON t0_D.id=t1_D_bs.D_FK
LEFT OUTER JOIN C t2_D_cs ON t0_D.id=t2_D_cs.D_FK
WHERE t0_D.id=?
SELECT t0_D.id, t0_D.name,
t1_D_bs.id, t1_D_bs.name,
t2_D_cs.id, t2_D_cs.name
FROM D t0_D
LEFT OUTER JOIN B t1_D_bs ON t0_D.id=t1_D_bs.D_FK
LEFT OUTER JOIN C t2_D_cs ON t0_D.id=t2_D_cs.D_FK
WHERE t0_D.id=?
Copy to ClipboardCopied!Toggle word wrapToggle overflow
For the D with the specific id we preload all its related B's and C's and can access those instance loading them from the read ahead cache, not from the database.
In the same way, we could optimize the findAll method on D selects all the D's. A normal findAll query would look like this:
SELECT DISTINCT t0_o.id, t0_o.name FROM D t0_o ORDER BY t0_o.id DESC
SELECT DISTINCT t0_o.id, t0_o.name FROM D t0_o ORDER BY t0_o.id DESC
Copy to ClipboardCopied!Toggle word wrapToggle overflow
To preload the relations, we simply need to add the left-join elements to the query.
<query>
<query-method>
<method-name>findAll</method-name>
</query-method>
<jboss-ql><![CDATA[SELECT DISTINCT OBJECT(o) FROM D AS o ORDER BY o.id DESC]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="bs" eager-load-group="basic"/>
<left-join cmr-field="cs" eager-load-group="basic"/>
</read-ahead>
</query>
<query>
<query-method>
<method-name>findAll</method-name>
</query-method>
<jboss-ql><![CDATA[SELECT DISTINCT OBJECT(o) FROM D AS o ORDER BY o.id DESC]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="bs" eager-load-group="basic"/>
<left-join cmr-field="cs" eager-load-group="basic"/>
</read-ahead>
</query>
Copy to ClipboardCopied!Toggle word wrapToggle overflow
And here is the generated SQL:
SELECT DISTINCT t0_o.id, t0_o.name,
t1_o_bs.id, t1_o_bs.name,
t2_o_cs.id, t2_o_cs.name
FROM D t0_o
LEFT OUTER JOIN B t1_o_bs ON t0_o.id=t1_o_bs.D_FK
LEFT OUTER JOIN C t2_o_cs ON t0_o.id=t2_o_cs.D_FK
ORDER BY t0_o.id DESC
SELECT DISTINCT t0_o.id, t0_o.name,
t1_o_bs.id, t1_o_bs.name,
t2_o_cs.id, t2_o_cs.name
FROM D t0_o
LEFT OUTER JOIN B t1_o_bs ON t0_o.id=t1_o_bs.D_FK
LEFT OUTER JOIN C t2_o_cs ON t0_o.id=t2_o_cs.D_FK
ORDER BY t0_o.id DESC
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Now the simple findAll query now preloads the related B and C objects for each D object.
Now let us look at a more complex configuration. Here we want to preload instance A along with several relations.
its parent (self-relation) reached from A with CMR field parent
the B reached from A with CMR field b, and the related C reached from B with CMR field c
B reached from A but this time with CMR field b2 and related to it C reached from B with CMR field c.
For reference, the standard query would be:
SELECT t0_o.id, t0_o.name FROM A t0_o ORDER BY t0_o.id DESC FOR UPDATE
SELECT t0_o.id, t0_o.name FROM A t0_o ORDER BY t0_o.id DESC FOR UPDATE
Copy to ClipboardCopied!Toggle word wrapToggle overflow
The following metadata describes our preloading plan.
<query>
<query-method>
<method-name>findAll</method-name>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM A AS o ORDER BY o.id DESC]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="parent" eager-load-group="basic"/>
<left-join cmr-field="b" eager-load-group="basic">
<left-join cmr-field="c" eager-load-group="basic"/>
</left-join>
<left-join cmr-field="b2" eager-load-group="basic">
<left-join cmr-field="c" eager-load-group="basic"/>
</left-join>
</read-ahead>
</query>
<query>
<query-method>
<method-name>findAll</method-name>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM A AS o ORDER BY o.id DESC]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>basic</eager-load-group>
<left-join cmr-field="parent" eager-load-group="basic"/>
<left-join cmr-field="b" eager-load-group="basic">
<left-join cmr-field="c" eager-load-group="basic"/>
</left-join>
<left-join cmr-field="b2" eager-load-group="basic">
<left-join cmr-field="c" eager-load-group="basic"/>
</left-join>
</read-ahead>
</query>
Copy to ClipboardCopied!Toggle word wrapToggle overflow
The SQL query generated would be:
SELECT t0_o.id, t0_o.name,
t1_o_parent.id, t1_o_parent.name,
t2_o_b.id, t2_o_b.name,
t3_o_b_c.id, t3_o_b_c.name,
t4_o_b2.id, t4_o_b2.name,
t5_o_b2_c.id, t5_o_b2_c.name
FROM A t0_o
LEFT OUTER JOIN A t1_o_parent ON t0_o.PARENT=t1_o_parent.id
LEFT OUTER JOIN B t2_o_b ON t0_o.B_FK=t2_o_b.id
LEFT OUTER JOIN C t3_o_b_c ON t2_o_b.C_FK=t3_o_b_c.id
LEFT OUTER JOIN B t4_o_b2 ON t0_o.B2_FK=t4_o_b2.id
LEFT OUTER JOIN C t5_o_b2_c ON t4_o_b2.C_FK=t5_o_b2_c.id
ORDER BY t0_o.id DESC FOR UPDATE
SELECT t0_o.id, t0_o.name,
t1_o_parent.id, t1_o_parent.name,
t2_o_b.id, t2_o_b.name,
t3_o_b_c.id, t3_o_b_c.name,
t4_o_b2.id, t4_o_b2.name,
t5_o_b2_c.id, t5_o_b2_c.name
FROM A t0_o
LEFT OUTER JOIN A t1_o_parent ON t0_o.PARENT=t1_o_parent.id
LEFT OUTER JOIN B t2_o_b ON t0_o.B_FK=t2_o_b.id
LEFT OUTER JOIN C t3_o_b_c ON t2_o_b.C_FK=t3_o_b_c.id
LEFT OUTER JOIN B t4_o_b2 ON t0_o.B2_FK=t4_o_b2.id
LEFT OUTER JOIN C t5_o_b2_c ON t4_o_b2.C_FK=t5_o_b2_c.id
ORDER BY t0_o.id DESC FOR UPDATE
Copy to ClipboardCopied!Toggle word wrapToggle overflow
With this configuration, you can navigate CMRs from any found instance of A without an additional database load.
Here is another example of self-relation. Suppose, we want to write a method that would preload an instance, its parent, grand-parent and its grand-grand-parent in one query. To do this, we would used nested left-join declaration.
<query>
<query-method>
<method-name>findMeParentGrandParent</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM A AS o WHERE o.id = ?1]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>*</eager-load-group>
<left-join cmr-field="parent" eager-load-group="basic">
<left-join cmr-field="parent" eager-load-group="basic">
<left-join cmr-field="parent" eager-load-group="basic"/>
</left-join>
</left-join>
</read-ahead>
</query>
<query>
<query-method>
<method-name>findMeParentGrandParent</method-name>
<method-params>
<method-param>java.lang.Long</method-param>
</method-params>
</query-method>
<jboss-ql><![CDATA[SELECT OBJECT(o) FROM A AS o WHERE o.id = ?1]]></jboss-ql>
<read-ahead>
<strategy>on-find</strategy>
<page-size>4</page-size>
<eager-load-group>*</eager-load-group>
<left-join cmr-field="parent" eager-load-group="basic">
<left-join cmr-field="parent" eager-load-group="basic">
<left-join cmr-field="parent" eager-load-group="basic"/>
</left-join>
</left-join>
</read-ahead>
</query>
Copy to ClipboardCopied!Toggle word wrapToggle overflow
The generated SQL would be:
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B_FK, t0_o.B2_FK, t0_o.PARENT,
t1_o_parent.id, t1_o_parent.name,
t2_o_parent_parent.id, t2_o_parent_parent.name,
t3_o_parent_parent_parent.id, t3_o_parent_parent_parent.name
FROM A t0_o
LEFT OUTER JOIN A t1_o_parent ON t0_o.PARENT=t1_o_parent.id
LEFT OUTER JOIN A t2_o_parent_parent ON t1_o_parent.PARENT=t2_o_parent_parent.id
LEFT OUTER JOIN A t3_o_parent_parent_parent
ON t2_o_parent_parent.PARENT=t3_o_parent_parent_parent.id
WHERE (t0_o.id = ?) FOR UPDATE
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B_FK, t0_o.B2_FK, t0_o.PARENT,
t1_o_parent.id, t1_o_parent.name,
t2_o_parent_parent.id, t2_o_parent_parent.name,
t3_o_parent_parent_parent.id, t3_o_parent_parent_parent.name
FROM A t0_o
LEFT OUTER JOIN A t1_o_parent ON t0_o.PARENT=t1_o_parent.id
LEFT OUTER JOIN A t2_o_parent_parent ON t1_o_parent.PARENT=t2_o_parent_parent.id
LEFT OUTER JOIN A t3_o_parent_parent_parent
ON t2_o_parent_parent.PARENT=t3_o_parent_parent_parent.id
WHERE (t0_o.id = ?) FOR UPDATE
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Note, if we remove left-join metadata we will have only
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B2_FK, t0_o.PARENT FOR UPDATE
SELECT t0_o.id, t0_o.name, t0_o.secondName, t0_o.B2_FK, t0_o.PARENT FOR UPDATE
Copy to ClipboardCopied!Toggle word wrapToggle overflow
Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.
Hacer que el código abierto sea más inclusivo
Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.
Acerca de Red Hat
Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.
Red Hat Summit
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}