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
