You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Clemens Wyss DEV <cl...@mysign.ch> on 2015/01/20 11:18:37 UTC
transactions@Solr(J)
http://stackoverflow.com/questions/10805117/solr-transaction-management-using-solrj
Is it true, that a SolrServer-instance denotes a "transaction context"?
Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the same core. Then each thread can add/update/delete documents without "affecting" the other thread/SolrServer-instance?
Must <autoCommit> be switched off for this to work?
Re: AW: AW: AW: transactions@Solr(J)
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/21/2015 9:15 AM, Clemens Wyss DEV wrote:
> What I meant is:
> If I do SolrServer#rollback after 11 documents were added, will then only 1 or all 11 docments that have been added "in the SolrServer-tranascation/context"?
If autoCommit is set to 10 docs and openSearcher is true, it would roll
back one document, assuming that the 11th document didn't make it into
the index before the commit actually started. I'm not sure if the
autoCommit settings are perfectly atomic, or if there would be enough of
a time gap to allow a few more documents to make it in. If you added
the documents one at a time, I could be sure that the rollback would be
one document.
If openSearcher is false, I'm not sure whether it would do one or 11. I
just don't know enough about the underlying API.
Thanks,
Shawn
AW: AW: AW: transactions@Solr(J)
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
What I meant is:
If I do SolrServer#rollback after 11 documents were added, will then only 1 or all 11 docments that have been added "in the SolrServer-tranascation/context"?
-----Ursprüngliche Nachricht-----
Von: Shawn Heisey [mailto:apache@elyograg.org]
Gesendet: Mittwoch, 21. Januar 2015 15:24
An: solr-user@lucene.apache.org
Betreff: Re: AW: AW: transactions@Solr(J)
On 1/20/2015 11:42 PM, Clemens Wyss DEV wrote:
> But then what happens if:
> Autocommit is set to 10 docs
> and
> I add 11 docs and then decide (due to an exception?) to rollback.
>
> Will only one (i.e. the last added) document be rollen back?
The way I understand the low-level architecture, yes -- assuming that all 11 documents actually got indexed. If the exception happened because of document 5 was badly formed, only documents 1-4 will have been indexed, and in that case, all four of them would get rolled back.
Thanks,
Shawn
Re: AW: AW: transactions@Solr(J)
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/20/2015 11:42 PM, Clemens Wyss DEV wrote:
> But then what happens if:
> Autocommit is set to 10 docs
> and
> I add 11 docs and then decide (due to an exception?) to rollback.
>
> Will only one (i.e. the last added) document be rollen back?
The way I understand the low-level architecture, yes -- assuming that
all 11 documents actually got indexed. If the exception happened
because of document 5 was badly formed, only documents 1-4 will have
been indexed, and in that case, all four of them would get rolled back.
Thanks,
Shawn
AW: AW: transactions@Solr(J)
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
But then what happens if:
Autocommit is set to 10 docs
and
I add 11 docs and then decide (due to an exception?) to rollback.
Will only one (i.e. the last added) document be rollen back?
-----Ursprüngliche Nachricht-----
Von: Michael Sokolov [mailto:msokolov@safaribooksonline.com]
Gesendet: Dienstag, 20. Januar 2015 16:10
An: solr-user@lucene.apache.org
Betreff: Re: AW: transactions@Solr(J)
Yes -- autoCommit works just the same as if you had a timer in your app committing. You have to turn it off if you want to maintain the ability to roll back predictably.
-Mike
On 01/20/2015 09:19 AM, Clemens Wyss DEV wrote:
> Thanks Mike,
>> but a key difference is that when one client commits, all clients
>> will see the updates
> That's ok.
>
> What about the <autoCommit>-setting(s) in solrconfig.xml. Doesn't this mean that after adding x elements (or after a certain timeframe), the changes are commited and hence no more rollbackable? Or do the autoCommit-settings only affect/control the commits to the Solr-transaction.log?
>
> -Clemens
>
> -----Ursprüngliche Nachricht-----
> Von: Michael Sokolov [mailto:msokolov@safaribooksonline.com]
> Gesendet: Dienstag, 20. Januar 2015 14:54
> An: solr-user@lucene.apache.org
> Betreff: Re: transactions@Solr(J)
>
> On 1/20/2015 5:18 AM, Clemens Wyss DEV wrote:
>> http://stackoverflow.com/questions/10805117/solr-transaction-manageme
>> n t-using-solrj Is it true, that a SolrServer-instance denotes a
>> "transaction context"?
>>
>> Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the same core. Then each thread can add/update/delete documents without "affecting" the other thread/SolrServer-instance?
>> Must <autoCommit> be switched off for this to work?
> Solr does not provide transactional isolation like you might be familiar with from a relational DB. There are commit and rollback, so no updates are seen until a commit (including autocommit), but a key difference is that when one client commits, all clients will see the updates, since index readers are shared, not associated with a specific client. The underlying Lucene index has the ability to maintain an open reader even after another writer has issued a commit, but this isn't accessible via Solr.
>
> -Mike
Re: AW: transactions@Solr(J)
Posted by Michael Sokolov <ms...@safaribooksonline.com>.
Yes -- autoCommit works just the same as if you had a timer in your app
committing. You have to turn it off if you want to maintain the ability
to roll back predictably.
-Mike
On 01/20/2015 09:19 AM, Clemens Wyss DEV wrote:
> Thanks Mike,
>> but a key difference is that when one client commits, all clients will see the updates
> That's ok.
>
> What about the <autoCommit>-setting(s) in solrconfig.xml. Doesn't this mean that after adding x elements (or after a certain timeframe), the changes are commited and hence no more rollbackable? Or do the autoCommit-settings only affect/control the commits to the Solr-transaction.log?
>
> -Clemens
>
> -----Ursprüngliche Nachricht-----
> Von: Michael Sokolov [mailto:msokolov@safaribooksonline.com]
> Gesendet: Dienstag, 20. Januar 2015 14:54
> An: solr-user@lucene.apache.org
> Betreff: Re: transactions@Solr(J)
>
> On 1/20/2015 5:18 AM, Clemens Wyss DEV wrote:
>> http://stackoverflow.com/questions/10805117/solr-transaction-managemen
>> t-using-solrj Is it true, that a SolrServer-instance denotes a
>> "transaction context"?
>>
>> Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the same core. Then each thread can add/update/delete documents without "affecting" the other thread/SolrServer-instance?
>> Must <autoCommit> be switched off for this to work?
> Solr does not provide transactional isolation like you might be familiar with from a relational DB. There are commit and rollback, so no updates are seen until a commit (including autocommit), but a key difference is that when one client commits, all clients will see the updates, since index readers are shared, not associated with a specific client. The underlying Lucene index has the ability to maintain an open reader even after another writer has issued a commit, but this isn't accessible via Solr.
>
> -Mike
AW: transactions@Solr(J)
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
Thanks Mike,
> but a key difference is that when one client commits, all clients will see the updates
That's ok.
What about the <autoCommit>-setting(s) in solrconfig.xml. Doesn't this mean that after adding x elements (or after a certain timeframe), the changes are commited and hence no more rollbackable? Or do the autoCommit-settings only affect/control the commits to the Solr-transaction.log?
-Clemens
-----Ursprüngliche Nachricht-----
Von: Michael Sokolov [mailto:msokolov@safaribooksonline.com]
Gesendet: Dienstag, 20. Januar 2015 14:54
An: solr-user@lucene.apache.org
Betreff: Re: transactions@Solr(J)
On 1/20/2015 5:18 AM, Clemens Wyss DEV wrote:
> http://stackoverflow.com/questions/10805117/solr-transaction-managemen
> t-using-solrj Is it true, that a SolrServer-instance denotes a
> "transaction context"?
>
> Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the same core. Then each thread can add/update/delete documents without "affecting" the other thread/SolrServer-instance?
> Must <autoCommit> be switched off for this to work?
Solr does not provide transactional isolation like you might be familiar with from a relational DB. There are commit and rollback, so no updates are seen until a commit (including autocommit), but a key difference is that when one client commits, all clients will see the updates, since index readers are shared, not associated with a specific client. The underlying Lucene index has the ability to maintain an open reader even after another writer has issued a commit, but this isn't accessible via Solr.
-Mike
Re: transactions@Solr(J)
Posted by Michael Sokolov <ms...@safaribooksonline.com>.
On 1/20/2015 5:18 AM, Clemens Wyss DEV wrote:
> http://stackoverflow.com/questions/10805117/solr-transaction-management-using-solrj
> Is it true, that a SolrServer-instance denotes a "transaction context"?
>
> Say I have two concurrent threads, each having a SolrServer-instance "pointing" to the same core. Then each thread can add/update/delete documents without "affecting" the other thread/SolrServer-instance?
> Must <autoCommit> be switched off for this to work?
Solr does not provide transactional isolation like you might be familiar
with from a relational DB. There are commit and rollback, so no updates
are seen until a commit (including autocommit), but a key difference is
that when one client commits, all clients will see the updates, since
index readers are shared, not associated with a specific client. The
underlying Lucene index has the ability to maintain an open reader even
after another writer has issued a commit, but this isn't accessible via
Solr.
-Mike