[
https://issues.apache.org/jira/browse/SOLR-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089783#comment-13089783
]
Simon Rosenthal commented on SOLR-2664:
---------------------------------------
bq. Rather than disabling autoCommit globally (for all clients), shouldn't it
just disable it for that particular client? A different client may be adding
some time sensitive documents.
That's a much better approach! I like the "batch" parameter. Is it in fact now
possible to autocommit (or not, in this case) only for a particular content
stream/batch, when multiple ones are being indexed simultaneoulsy ? (my
understanding has always been that commits/autocommits were global in effect).
> Disable/enable autocommit on the fly
> ------------------------------------
>
> Key: SOLR-2664
> URL: https://issues.apache.org/jira/browse/SOLR-2664
> Project: Solr
> Issue Type: New Feature
> Components: update
> Affects Versions: 4.0
> Reporter: Simon Rosenthal
> Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2664.patch
>
>
> There are occasions when although autocommit is configured, it would be
> desirable to disable it temporarily - for instance when batch adding/updating
> a set of documents which should be committed atomically (e.g. a set of price
> changes).
> The patch adds <disableAutoCommit/> and </enableAutoCommit> commands to
> XMLUpdateHandler, and also adds a disableAutoCommit=true|false attribute to
> the <add> element - this will disable autocommit until the terminating </add>
> at the end of the XML document is reached.
> At present, the autocommit state will not survive a core reload.
> It should be possible to extend this functionality to SolrJ, CSVUpdatehandler
> ( and JSONUpdateHandler ?)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
