[
https://issues.apache.org/jira/browse/JCR-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553588
]
Jukka Zitting commented on JCR-1253:
------------------------------------
I looked at this a bit deeper and found out that there is no other way to avoid
the extra roundtrip with jdts, as it uses a "SET IMPLICIT_TRANSACTIONS"
statement to control the autocommit mode.
In the long run I think we should move towards using a connection pool, which
would nicely solve also this issue. Meanwhile I'm not sure what would be the
best way to avoid the setAutoCommit overhead.
You should be able to run even a Jackrabbit cluster using the READ COMMITTED
isolation level, so given a database that supports the READ COMMITTED level
without having to lock things after SELECTs there might be a case for disabling
autocommit without explicitly committing the read operations. Such a thing
should probably go into a separate BundleDbPM subclass, and I'm not sure
whether that's worth the effort.
> 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.4
> Reporter: Przemo Pakulski
> Priority: Minor
> Fix For: 1.4
>
> Attachments: JCR-1253.patch, 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.
