[
https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547849
]
Przemo Pakulski commented on JCR-1253:
--------------------------------------
Notice, that I marked this improvement as MINOR, it does not affect overall
performance a lot. I simply don't like switching autoCommit mode every time if
it is not really needed (2 more chances to get SQLException :-))
Here is example code you can use (change log is small):
Credentials credentials = new SimpleCredentials("admin", "admin"
.toCharArray());
Session session = repository.login(credentials);
Node testNode = session.getRootNode().addNode("testNode");
session.save();
for (int i = 0; i < 10000; i++) {
testNode.setProperty("int", i);
testNode.save();
}
session.logout();
with this test handling of autoCommit mode takes about 25% of the time of store
method, basing on profiler reports. I'm testing 1.3.3 but there is no much
difference I think.
> Allow to configure autoCommit mode for BundleDB PM to avoid extra overhead
> when working in non clustered environment
> --------------------------------------------------------------------------------------------------------------------
>
> Key: JCR-1253
> URL: https://issues.apache.org/jira/browse/JCR-1253
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 1.3.3, 1.4
> Reporter: Przemo Pakulski
> Priority: Minor
> Fix For: 1.4
>
> Attachments: single_checkin.JPG, small_change_log.JPG
>
>
> BundleDB PMs keeps connection open in autoCommit mode and during every store
> operation turn off/on this flag introducing some overhead.
> '... the reason is that in a clustered environment, the 'select' statements
> must be committed as well, otherwise the tables remain locked. and
> instead of explicitly commit each time after a read, we used the
> autocommit as default and switch it off during store ...'
> We could add additional parameter which allows to configure autoCommit mode,
> by default it could work as before, but specifing additional parameter will
> change the behaviour.
> It's hard to say about exact numbers how much overhead it is, there are to
> many variables (network speed/latency, db server type, jdbc driver, change
> log size). For sure it means 2 extra network calls, which could be easily
> avoided.
> See attached example screen from JProfiler using MSSQL server, and small
> change logs; overhead is about 20%. Doing simple checkin on versionable node
> it could be even 40%.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
