The clustered cache just notifies other caches of updates. I'm not sure how foolproof the locking is in the clustered environment as I don't believe its been tested. I asked the same question myself. Fortunately, my application maintains its own locking on top of slide's and the application locks are stored in a shared db table. Application locking won't be enough when we expose our repository to external WebDAV clients though.
Warwick -----Original Message----- From: kranga [mailto:[EMAIL PROTECTED] Sent: Monday, September 13, 2004 5:52 PM To: Slide Users Mailing List Subject: Re: Using the slide api directly vs. using the webdav client Warwick, In the clustered configuration, are operations guaranteed to be atomic and exclusive? If I have two simultaneous requests going to two servers, will the servers attempt to gain a distributed lock (or an exclusive lock on the underlying table like a row or table lock)? Or is the clustering simply using a cache invalidation notification? ----- Original Message ----- From: "Warwick Burrows" <[EMAIL PROTECTED]> To: "'Slide Users Mailing List'" <[EMAIL PROTECTED]> Sent: Monday, September 13, 2004 3:57 PM Subject: RE: Using the slide api directly vs. using the webdav client > > I don't know much about the slide API, but would it be fair to say > that the > WebDAV client is a distributed HTTP client/server design that can be > made to > scale more easily and be more fault tolerant for large scale > deployments? Since the slide DAV servers can be HTTP load-balanced and > configured in a clustered configuration and the WebDAV client can make > requests transparently to any slide server? > > Or is the slide API also a remote API to the slide server too? > > Warwick > > > > -----Original Message----- > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > Sent: Monday, September 13, 2004 2:48 PM > To: 'Slide Users Mailing List' > Subject: RE: Using the slide api directly vs. using the webdav client > > > Nick, > > first of all, as Kiran has already said, performance should be better. Then, > getting rid of one extra layer that you might not need should make > your app > more robust. Webdav client has its fair share of bugs, afaik. Finally, slide > core api is more handy. It's just my opinion, of course, and I'm not > well familiar with the client. > > Yours sincerely, > Andrey. > > > -----Original Message----- > > From: Slide Users Mailing List > > [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 13, 2004 3:13 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Using the slide api directly vs. using the webdav client > > Importance: Low > > > > Andrey > > > > That's very interesting to hear. I had been intending to do all my > > work with the slide api, as opposed to the webdav api. So, for > > creating structure ("folders", users, adding > > documents) I can use the server api, but for checking out and > > versioning documents, I will have to use the webdav api. > > > > Do you see any inherent advantage beyond this to using one api over > > the other ? (ie, webdav vs. server api) > > > > Nick > > > > -----Original Message----- > > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 13, 2004 2:08 PM > > To: 'Slide Users Mailing List' > > Subject: RE: Using the slide api directly vs. using the webdav > > client > > > > You are welcome. If you have more specific questions about slide > > "core" api, > > don't hesitate to ask. Just keep in mind that currently it is > > somewhat flawed - for instance, some important parts of > > versioning and binding mechanism are implemented in slide's > > "webdav" layer only. > > > > Yours sincerely, > > Andrey. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
