I have been approaching the problem slightly differently. Rather than have my clients talk to Xindice directly, I have an intermediate Server. All of my clients are JMS clients, my "Xindice" server is also a JMS client. My clients subscribe to "documents". My plan for replication is to have another "JMS Client/Server" also subscribe. It listens for changes and updates Xindice silently in the background. If one dies, it steps up and takes over.
Mark Matt Liotta wrote: > ic, I am currently generating globally unique identifiers for all > documents no matter what collection they are in. This would of course > all my application to make use of replication without fear of documents > in different collections colliding. However, this wouldn't work for all > applications, which is why I was suggesting the concatenation of the > collection identifier with the document identifier. > > -Matt > > > -----Original Message----- > > From: Sean Kelly [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 12, 2002 11:34 AM > > To: [EMAIL PROTECTED] > > Subject: RE: replication > > > > > I thought Xindice only enforced unique document identifiers at the > > > collection level. What's to stop someone from adding the same > document > > > uuid to another collection? > > > > Nothing. > > > > By virtue of joining the same peergroup, peers agree that the same ID > for > > a > > document means the same document. If two peers want the same ID to > refer > > to > > different documents, they must belong to different peergroups. > > > > In other words, it's up to the peergroup to provide an ID policy and > > mechanism. > > > > -- > > Sean Kelly > > Independent Consultant > > http://kelly.homeunix.com/ -- Mark J Stang Architect Cybershop Systems
begin:vcard n:Stang;Mark x-mozilla-html:TRUE adr:;;;;;; version:2.1 email;internet:[EMAIL PROTECTED] fn:Mark Stang end:vcard
