Hi, I'm with the transaction problem too: I have Documents which are represented by a Business Object (persisted in a DB with an ORM), indexed with Lucene and finally stored in the file system. So it's very difficult to maintain the consistency in an error scenario. The main problem is that if you implement some ad-hoc transaction with Lucene (working in a RAMDirectory or keeping the commands to apply until the end), you still have to coordinate the lucene transaction with the others. Cause if lucene transaction rollbacks you can abort the db transaction, but if lucene transaction commits you can't do anything if the DB transaction fails with out a 3pc transaction manager. Does Anybody have an idea about how to reduce the error time window? Could this problem be solved storing the index in a database?
Thanks Beto
Marios Skounakis wrote:
Hi all, I am interested in developing a system which will use Lucene to implement the search functionality. A key characteristic of this system is that certain information about the indexed documents will be editable by the user administrators. For instance, the user administrators can manually create "document collections" and assign some of the indexed documents to them. One way to implement document collections would by having documents have a dedicated field for storing the document collection id, and storing the document collection information in a database. Ideally, such an operation as the above should have transactional semantics, i.e. if a user wants to assign documents x, y and z to collection C, then either all three documents should be assigned to the collection or, in case of error, none of the documents should be assigned to the collection. Also, if the operation were to be followed by an SQL query to update the database with the number of documents assigned to collection C, that should be included in the "transaction" as well. Is there a straightforward way to do this with Lucene? Or are "transactions" a no-no for a system like Lucene and I should just go ahead without having transactional semantics? Thanks in advance, Marios Skounakis ------------------------------------------------------------------------ No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.1/169 - Release Date: 11/15/2005
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
