Re: AW: AW: AW: Performance

Björn Eickvonder wrote:
> So it's really xupdate..., unfortunately I couldn't find the sources for the
> xupdate implementation or better a working cvs or subversion address. Do you
> have any that works?
> 

I have also created a patch to eliminate the temporaryTree nodes that
get left around. If we can convince Vadim to use a custom xupdate.jar I
might invistage refactoring the library to remove that static variable.

Here is the way to get the source tree:
cvs -d:pserver:[email protected]:/cvsroot/xmldb-org login
cvs -z3 -d:pserver:[email protected]:/cvsroot/xmldb-org co
-P xupdate

The project page is here: http://sourceforge.net/projects/xmldb-org/

> According to your comment it sounds like that any two xupdates can conflict
> no matter on which document of which collections it is ever executed. So if
> a person A1 is editing a document B1 in a collection C1 and a person A1 is
> editing B2 in C2 via xupdates at the same time, there is a chance that one
> or both files are "corrupt"? So my workaround to synchronize xupdates per
> collection only decreases the possibility of corrupt files but does not
> eliminate it? So the only possible solution without touching the sources of
> xupdate (which I couldn't find as mentioned above) would be to synchronize
> all xupdates over the whole database or not to use xupdates at all?!?
> 

Pretty much unfortatenly. I have a driver infront of Xindice and just
lock the whole thing down before processing the commands. On a side note
use xupdate for admin commands and only allow users to save whole files.

> Bjoern Eickvonder
> 
> PS: By the way where and in what kind of form can/should I post XIndice
> patches that I developed like a solution for the "too many open files
> problem" that can occur on linux systems (if you have a large number of
> collections)?
> 
Just post them to [email protected] with PATCH in the title.
Vadim will take a look at them when he has time.

Todd
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Todd Byrne [mailto:[email protected]]
>>Gesendet: Donnerstag, 28. Juli 2005 20:10
>>An: [email protected]
>>Betreff: Re: AW: AW: Performance
>>
>>
>>The xupdate implementation that Xindice uses isn't thread safe. The
>>xupdate code uses a global static variable to hold temporary nodes.
>>Their is also others cases where temporary elements can be left around
>>but I haven't been able to get the patch commited on the xupdate side.
>>
>>Todd
>>
>>Eickvonder Bjoern wrote:
>>
>>>I use b4 and it does occur if multiple users are manipulating
>>
>>different documents in a collection via xupdates, especially
>>those commands that append elements. In that case sometimes some
>>of the appended elements are missing or a document contains
>>elements that would normally belong to another document. I
>>tracked this issue a little bit and I think it is maybe somewhere
>>in the xupdate implementation, that is used, so it is not
>>entirely an xindice problem.
>>
>>>Björn Eickvonder
>>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Vadim Gritsenko [mailto:[email protected]]
>>>Gesendet: Donnerstag, 28. Juli 2005 16:33
>>>An: [email protected]
>>>Betreff: Re: AW: Performance
>>>
>>>Eickvonder Bjoern wrote:
>>>
>>>
>>>>Moreover I had problems if multiple users are adding/writing
>>>>(different) files to a collection concurrently (some data was later on
>>>>corrupt or missing), so I had to synchronize the write access to each
>>>>collection.
>>>
>>>
>>>What xindice version did you use. I've not seen corruptions since b4.
>>>
>>>Vadim
>>>
>>>
>>>
>>>
>>>____________
>>>Virus checked by G DATA AntiVirusKit
>>>Version: AVK 15.0.6273 from 27.07.2005
>>
> 
> ____________
> Virus checked by G DATA AntiVirusKit
> Version: AVK 15.0.6302 from 28.07.2005