lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Hadfield <m...@animarc.com>
Subject Re: Lucene & Transactional semantics
Date Thu, 17 Nov 2005 21:28:47 GMT

The Compass Framework ( 
http://www.compassframework.org/display/SITE/Home) implements 
transactional semantics "on top" of Lucene, such that you can treat the 
Lucene Index as an ORM-style database.  Compass uses a recent version of 
Lucene but I'm sure some functionality is abstracted out and performance 
penalties occur, although I can't say how much of a hit it is.


Best,
Marc Hadfield


Beto Siless wrote:

>
> 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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message