On 3/23/07, Steven Parkes (JIRA) <[EMAIL PROTECTED]> wrote:
In fact, there a few things here that are fairly subtle/important. The relationship/protocol between the writer and policy is pretty strong. This can be seen in the strawman concurrent merge code where the merge policy holds state and relies on being called from a synchronized writer method. If that goes forward anything like it is, it would argue for tightening that api up some. Chris suggested a way to make the writer<>polcy relationship "atomic". I didn't add the code (yet) but I'm not against it.
What does "atomic" mean here? I'm thinking, can we move segmentInfos from IndexWriter to merge policy? This way, IndexWriter is in charge of in-mem part and inserts and deletes, and merge policy is in charge of disk part and merges. Then only IndexWriter calls methods in merge policy but not the other way around. Also, it'll be much easier to support concurrent merges in a merge policy when it owns segmentInfos. Just my two cents. Regards, Ning --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
