Repository: cayenne Updated Branches: refs/heads/master 43a0af870 -> 7decb6ce0
Docs * Java 7 switch allows us to take a few shortcuts, namely try-with-resources * documenting ResultBatchIterator Project: http://git-wip-us.apache.org/repos/asf/cayenne/repo Commit: http://git-wip-us.apache.org/repos/asf/cayenne/commit/7decb6ce Tree: http://git-wip-us.apache.org/repos/asf/cayenne/tree/7decb6ce Diff: http://git-wip-us.apache.org/repos/asf/cayenne/diff/7decb6ce Branch: refs/heads/master Commit: 7decb6ce098ed89e64c204b5c9c725074a6f479f Parents: 43a0af8 Author: aadamchik <aadamc...@apache.org> Authored: Sat Sep 26 20:53:44 2015 +0300 Committer: aadamchik <aadamc...@apache.org> Committed: Sat Sep 26 20:54:49 2015 +0300 ---------------------------------------------------------------------- .../src/docbkx/performance-tuning.xml | 27 +++++++++++--------- 1 file changed, 15 insertions(+), 12 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/cayenne/blob/7decb6ce/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml ---------------------------------------------------------------------- diff --git a/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml b/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml index 06b98ec..2cff9a9 100644 --- a/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml +++ b/docs/docbook/cayenne-guide/src/docbkx/performance-tuning.xml @@ -198,30 +198,33 @@ for(DataRow row : rows) { closing to avoid JDBC resources leak, or a callback that lets Cayenne handle resource management. In both cases iteration can be performed using "for" loop, as ResultIterator is "Iterable".</para> - <para>Direct access. Here common sense tells us that ResultIterators instances should be + <para>Direct access. Here common sense tells us that ResultIterators instances should be processed and closed as soon as possible to release the DB connection. E.g. storing open iterators between HTTP requests for unpredictable length of time would quickly exhaust the connection - pool.<programlisting language="java">// create a regular query -SelectQuery<Artist> q = new SelectQuery<Artist>(Artist.class); - -ResultIterator<Artist> it = context.iterator(q); -try { + pool.<programlisting language="java">try(ResultIterator<Artist> it = ObjectSelect.query(Artist.class).iterator(context)) { for(Artist a : it) { // do something with the object... ... } -} -finally { - it.close(); }</programlisting></para> <para>Same thing with a - callback:<programlisting>SelectQuery<Artist> q = new SelectQuery<Artist>(Artist.class); - -context.iterate(q, (Artist a) -> { + callback:<programlisting>ObjectSelect.query(Artist.class).iterate(context, (Artist a) -> { // do something with the object... ... });</programlisting></para> + <para>Another example is a BatchIterator that allows to process more than one object in each + iteration. This is a common scenario in various data processing jobs - read a batch of + objects, process them, commit the results, and then repeat. This allows to further + optimize processing (e.g. by avoiding frequent + commits).<programlisting>try(ResultBatchIterator<Artist> it = ObjectSelect.query(Artist.class).iterator(context)) { + for(List<Artist> list : it) { + // do something with each list + ... + // possibly commit your changes + context.commitChanges(); + } +}</programlisting></para> </section> <section xml:id="paginated-queries"> <title>Paginated Queries</title>
