hibernate search + indexing with transaction issue -------------------------------------------------- Key: HSEARCH-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Reporter: Yan Falken Fix For: 3.1.1 Hi, I have the following problem with indexing in transaction with hibernate search: in case the transaction is opened and I want to perform multiple work types - only one type is actually performed after the commit and the others are ignored; example: TransactionManager tm = new DummyTransactionManager(); tm.begin(); SEntity se1 = new SEntity(10, "first", "second", true); Work delete = new Work(se1, "100", WorkType.DELETE); Work add = new Work(se1, "100", WorkType.ADD); Ctx ctx = new Ctx(tm.getTransaction()); searchFactory.getWorker().performWork(delete, ctx); searchFactory.getWorker().performWork(add, ctx); tm.commit(); only DELETE is performed - ADD is ignored log: 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity. 2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...) 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired. // opened 2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened // only remove 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader. 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace I digged into the code a little bit and there is class method: org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works if ( workType == WorkType.DELETE ) { //TODO add PURGE? //DELETE should have precedence over any update before (HSEARCH-257) //if an Add work is here, remove it //if an other delete is here remember but still search for Add if ( luceneWork instanceof AddLuceneWork ) { toDelete.add( luceneWork ); } else if ( luceneWork instanceof DeleteLuceneWork ) { duplicateDelete = true; } } else { //we can safely say we are out, the other work is an ADD return; } I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue. There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.

hibernate search + indexing with transaction issue -------------------------------------------------- Key: HSEARCH-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Reporter: Yan Falken Assignee: Sanne Grinovero Fix For: 3.1.1 Hi, I have the following problem with indexing in transaction with hibernate search: in case the transaction is opened and I want to perform multiple work types - only one type is actually performed after the commit and the others are ignored; example: TransactionManager tm = new DummyTransactionManager(); tm.begin(); SEntity se1 = new SEntity(10, "first", "second", true); Work delete = new Work(se1, "100", WorkType.DELETE); Work add = new Work(se1, "100", WorkType.ADD); Ctx ctx = new Ctx(tm.getTransaction()); searchFactory.getWorker().performWork(delete, ctx); searchFactory.getWorker().performWork(add, ctx); tm.commit(); only DELETE is performed - ADD is ignored log: 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity. 2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...) 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired. // opened 2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened // only remove 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader. 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace I digged into the code a little bit and there is class method: org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works if ( workType == WorkType.DELETE ) { //TODO add PURGE? //DELETE should have precedence over any update before (HSEARCH-257) //if an Add work is here, remove it //if an other delete is here remember but still search for Add if ( luceneWork instanceof AddLuceneWork ) { toDelete.add( luceneWork ); } else if ( luceneWork instanceof DeleteLuceneWork ) { duplicateDelete = true; } } else { //we can safely say we are out, the other work is an ADD return; } I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue. There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.

removing an entity and adding another with same PK (in same TX) will not add second entity to index ---------------------------------------------------------------------------------------------------- Key: HSEARCH-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Reporter: Yan Falken Assignee: Sanne Grinovero Fix For: 3.1.1, 3.2.0 Hi, I have the following problem with indexing in transaction with hibernate search: in case the transaction is opened and I want to perform multiple work types - only one type is actually performed after the commit and the others are ignored; example: TransactionManager tm = new DummyTransactionManager(); tm.begin(); SEntity se1 = new SEntity(10, "first", "second", true); Work delete = new Work(se1, "100", WorkType.DELETE); Work add = new Work(se1, "100", WorkType.ADD); Ctx ctx = new Ctx(tm.getTransaction()); searchFactory.getWorker().performWork(delete, ctx); searchFactory.getWorker().performWork(add, ctx); tm.commit(); only DELETE is performed - ADD is ignored log: 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity. 2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...) 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired. // opened 2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened // only remove 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader. 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace I digged into the code a little bit and there is class method: org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works if ( workType == WorkType.DELETE ) { //TODO add PURGE? //DELETE should have precedence over any update before (HSEARCH-257) //if an Add work is here, remove it //if an other delete is here remember but still search for Add if ( luceneWork instanceof AddLuceneWork ) { toDelete.add( luceneWork ); } else if ( luceneWork instanceof DeleteLuceneWork ) { duplicateDelete = true; } } else { //we can safely say we are out, the other work is an ADD return; } I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue. There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.

removing an entity and adding another with same PK (in same TX) will not add second entity to index ---------------------------------------------------------------------------------------------------- Key: HSEARCH-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Reporter: Yan Falken Assignee: Sanne Grinovero Fix For: 3.1.1, 3.2.0 Hi, I have the following problem with indexing in transaction with hibernate search: in case the transaction is opened and I want to perform multiple work types - only one type is actually performed after the commit and the others are ignored; example: TransactionManager tm = new DummyTransactionManager(); tm.begin(); SEntity se1 = new SEntity(10, "first", "second", true); Work delete = new Work(se1, "100", WorkType.DELETE); Work add = new Work(se1, "100", WorkType.ADD); Ctx ctx = new Ctx(tm.getTransaction()); searchFactory.getWorker().performWork(delete, ctx); searchFactory.getWorker().performWork(add, ctx); tm.commit(); only DELETE is performed - ADD is ignored log: 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity. 2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...) 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired. // opened 2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened // only remove 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader. 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace I digged into the code a little bit and there is class method: org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works if ( workType == WorkType.DELETE ) { //TODO add PURGE? //DELETE should have precedence over any update before (HSEARCH-257) //if an Add work is here, remove it //if an other delete is here remember but still search for Add if ( luceneWork instanceof AddLuceneWork ) { toDelete.add( luceneWork ); } else if ( luceneWork instanceof DeleteLuceneWork ) { duplicateDelete = true; } } else { //we can safely say we are out, the other work is an ADD return; } I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue. There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.

removing an entity and adding another with same PK (in same TX) will not add second entity to index ---------------------------------------------------------------------------------------------------- Key: HSEARCH-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-353 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.GA Reporter: Yan Falken Assignee: Sanne Grinovero Fix For: 3.2.0 Hi, I have the following problem with indexing in transaction with hibernate search: in case the transaction is opened and I want to perform multiple work types - only one type is actually performed after the commit and the others are ignored; example: TransactionManager tm = new DummyTransactionManager(); tm.begin(); SEntity se1 = new SEntity(10, "first", "second", true); Work delete = new Work(se1, "100", WorkType.DELETE); Work add = new Work(se1, "100", WorkType.ADD); Ctx ctx = new Ctx(tm.getTransaction()); searchFactory.getWorker().performWork(delete, ctx); searchFactory.getWorker().performWork(add, ctx); tm.commit(); only DELETE is performed - ADD is ignored log: 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx 2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity. 2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...) 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired. // opened 2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened // only remove 2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader. 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed 2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace I digged into the code a little bit and there is class method: org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works if ( workType == WorkType.DELETE ) { //TODO add PURGE? //DELETE should have precedence over any update before (HSEARCH-257) //if an Add work is here, remove it //if an other delete is here remember but still search for Add if ( luceneWork instanceof AddLuceneWork ) { toDelete.add( luceneWork ); } else if ( luceneWork instanceof DeleteLuceneWork ) { duplicateDelete = true; } } else { //we can safely say we are out, the other work is an ADD return; } I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue. There should be ability to in single transaction perform multiple work types as there is no way how to control the client to perform just one work type.