Super! Thanks for testing this & posting...
Mike
<[EMAIL PROTECTED]> wrote:
I don't think creating an IndexWriter is very expensive at all.
Ah ok. I tested it. Creating an IndexWriter on an index with 10.000
docs
(about 15 MB) takes about 200 ms.
This is a very cheap operation for me ;
> I don't think creating an IndexWriter is very expensive at all.
Ah ok. I tested it. Creating an IndexWriter on an index with 10.000 docs
(about 15 MB) takes about 200 ms.
This is a very cheap operation for me ;)
I only saw the many calls in init() which reads files and so on and
therefore I to
I don't think creating an IndexWriter is very expensive at all.
Especially compared to creating an IndexReader, for example.
Mike
<[EMAIL PROTECTED]> wrote:
For what time is the 2.4 release planned?
Not really sure at this point ...
Hm. Digging into IndexWriter#init it seems that this is
> > For what time is the 2.4 release planned?
>
> Not really sure at this point ...
Hm. Digging into IndexWriter#init it seems that this is a really expensive
operation and thus my self made "commit" too. Isn't it?
-
To unsubsc
<[EMAIL PROTECTED]> wrote:
For what time is the 2.4 release planned?
Not really sure at this point ...
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> In 2.4, commit() sets the rollback point. So abort() will
> roll index
> back to the last time you called commit() (or to when the writer was
> opened if you haven't called commit).
>
> In 2.3, your only choice is to close & re-open the writer to reset
> the rollback point.
OK, thank yo
<[EMAIL PROTECTED]> wrote:
Then, you can call close() to commit the changes to the index, or
abort() to rollback the index to the starting state (when the writer
was opened).
As I understand the docs, the index will get rolled back to the
state as it
was when the index was opened.
How can
> Then, you can call close() to commit the changes to the index, or
> abort() to rollback the index to the starting state (when the writer
> was opened).
As I understand the docs, the index will get rolled back to the state as it
was when the index was opened.
How can I achieve a rollback which o
Lucene only allows for one open transaction at a time per index (IndexWriter).
So if you have multiple threads, and each of them is making changes,
all those changes will fall under one transaction, controlled by the
single writer the threads are sharing.
If you really want separate transactions,
Thanks Mike for you replay.
What about multithreading? If in one transaction can make both
adding and deleting documents and in the same time can be more then
one open transaction. Should each thread use it personal Index and
after commiting transaction somehow it merges or all threads must use o
You should open the IndexWriter with autoCommit=false, then make
changes. During this time, any reader that opens the index will not
see any changes you are making.
Then, you can call close() to commit the changes to the index, or
abort() to rollback the index to the starting state (when the writ
11 matches
Mail list logo
