Preferring RowCallbackHandler vs ResultSetExtractor
Both of these do the same thing: Is there a reason to prefer one over the other?
Map<Integer, String> ret = new HashMap<>();
jdbcTemplate.query(query, new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
ret.put(rs.getInt("id"), rs.getString("val"));
}
});
Map<Integer, String> ret = jdbcTemplate.query(query, new ResultSetExtractor<Map<Integer, String>>() {
@Override
public Map<Integer, String> extractData(ResultSet rs) throws SQLException {
Map<Integer, String> ret = new HashMap<>();
while(rs.next()) {
ret.put(rs.getInt("id"), rs.getString("val"));
}
return ret;
}
});
Code complexity seems about equal. Although the RowCallbackHandler is shorter it has a closure, and a function call. ResultSetExtractor is slightly longer, but only has local variables, and a loop instead of multiple function calls, on the other hand it repeats the data type 3 times.
Would ResultSetExtractor be faster (it's processing a lot of data, and is called frequently, so performance matters)?
Any options (or data) on which is better?
java spring jdbc spring-jdbc jdbctemplate
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
add a comment |
Both of these do the same thing: Is there a reason to prefer one over the other?
Map<Integer, String> ret = new HashMap<>();
jdbcTemplate.query(query, new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
ret.put(rs.getInt("id"), rs.getString("val"));
}
});
Map<Integer, String> ret = jdbcTemplate.query(query, new ResultSetExtractor<Map<Integer, String>>() {
@Override
public Map<Integer, String> extractData(ResultSet rs) throws SQLException {
Map<Integer, String> ret = new HashMap<>();
while(rs.next()) {
ret.put(rs.getInt("id"), rs.getString("val"));
}
return ret;
}
});
Code complexity seems about equal. Although the RowCallbackHandler is shorter it has a closure, and a function call. ResultSetExtractor is slightly longer, but only has local variables, and a loop instead of multiple function calls, on the other hand it repeats the data type 3 times.
Would ResultSetExtractor be faster (it's processing a lot of data, and is called frequently, so performance matters)?
Any options (or data) on which is better?
java spring jdbc spring-jdbc jdbctemplate
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
It depends - but IMORowCallbackHandlerallows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution withResultSetExtractorwhich collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.
– krokodilko
Nov 28 '18 at 21:52
add a comment |
Both of these do the same thing: Is there a reason to prefer one over the other?
Map<Integer, String> ret = new HashMap<>();
jdbcTemplate.query(query, new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
ret.put(rs.getInt("id"), rs.getString("val"));
}
});
Map<Integer, String> ret = jdbcTemplate.query(query, new ResultSetExtractor<Map<Integer, String>>() {
@Override
public Map<Integer, String> extractData(ResultSet rs) throws SQLException {
Map<Integer, String> ret = new HashMap<>();
while(rs.next()) {
ret.put(rs.getInt("id"), rs.getString("val"));
}
return ret;
}
});
Code complexity seems about equal. Although the RowCallbackHandler is shorter it has a closure, and a function call. ResultSetExtractor is slightly longer, but only has local variables, and a loop instead of multiple function calls, on the other hand it repeats the data type 3 times.
Would ResultSetExtractor be faster (it's processing a lot of data, and is called frequently, so performance matters)?
Any options (or data) on which is better?
java spring jdbc spring-jdbc jdbctemplate
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
Both of these do the same thing: Is there a reason to prefer one over the other?
Map<Integer, String> ret = new HashMap<>();
jdbcTemplate.query(query, new RowCallbackHandler() {
@Override
public void processRow(ResultSet rs) throws SQLException {
ret.put(rs.getInt("id"), rs.getString("val"));
}
});
Map<Integer, String> ret = jdbcTemplate.query(query, new ResultSetExtractor<Map<Integer, String>>() {
@Override
public Map<Integer, String> extractData(ResultSet rs) throws SQLException {
Map<Integer, String> ret = new HashMap<>();
while(rs.next()) {
ret.put(rs.getInt("id"), rs.getString("val"));
}
return ret;
}
});
Code complexity seems about equal. Although the RowCallbackHandler is shorter it has a closure, and a function call. ResultSetExtractor is slightly longer, but only has local variables, and a loop instead of multiple function calls, on the other hand it repeats the data type 3 times.
Would ResultSetExtractor be faster (it's processing a lot of data, and is called frequently, so performance matters)?
Any options (or data) on which is better?
java spring jdbc spring-jdbc jdbctemplate
java spring jdbc spring-jdbc jdbctemplate
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
edited Dec 12 '18 at 20:00
Ariel
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
asked Nov 28 '18 at 0:32
ArielAriel
20.4k34365
20.4k34365
It depends - but IMORowCallbackHandlerallows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution withResultSetExtractorwhich collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.
– krokodilko
Nov 28 '18 at 21:52
add a comment |
It depends - but IMORowCallbackHandlerallows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution withResultSetExtractorwhich collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.
– krokodilko
Nov 28 '18 at 21:52
It depends - but IMO
RowCallbackHandler allows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution with ResultSetExtractor which collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.– krokodilko
Nov 28 '18 at 21:52
It depends - but IMO
RowCallbackHandler allows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution with ResultSetExtractor which collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.– krokodilko
Nov 28 '18 at 21:52
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53510361%2fpreferring-rowcallbackhandler-vs-resultsetextractor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53510361%2fpreferring-rowcallbackhandler-vs-resultsetextractor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It depends - but IMO
RowCallbackHandlerallows you to save memory. Consider a report containing 1000000 rows, every row with a size of 3k bytes. The second solution withResultSetExtractorwhich collects all data in memory reqires 3GB of memory (6GB considering that each character in Java has 2 bytes). You hit either out-of-memory error or the server will start swapping memory to disk which will cause a huuuuuge slowdown. But the first solution is processing row-by-row, maybe a bit slower, but it needs a minimum amount of memory and you are safe from out-of-memory or swapping slowdown.– krokodilko
Nov 28 '18 at 21:52