Build your own or use whats out there. For Slide to have top-grade clustering either Slide must invest the time and effort to develop such a system or just use existing libraries that provide such capabilities. I would think that the correct approach is to build on whats out there, specifically, JGroups which has a distinguished academic pedigree, rich computer science heritage and significant usage. JGroups has distributed hashtables, distributed lock management, and, very appealing, group membership can be determined dynamically - one does not have to know every member of the group when the whole cluster starts.
Slide might have to be refactored some so that the clustering implementation is an addon and the main Slide code can compile and run without the JGroups jar file. But for those who wish to use Slide where clustering is a must, either for performance or failover, then the clustering implementation with its dependence on JGroups would have to be compiled and loaded.
Example usages: JBoss uses JGroups. CJDBC uses JGroups.
Richard
Warwick Burrows wrote:
We've implemented that configuration: a jdbc nodestore with tx filesystem
store much like you've outlined with a HTTP load balancer between our DAV
clients and Slide servers. It is untested in this target (load balanced)
configuration but we have tested in a simpler configuration that shares the
jdbc store and the content (using NFS) between two Slide servers.
Unfortunately the clustering implementation is untested in terms of how locking will work. Ie. when a lock is taken by one client a notification is sent to the other servers in the cluster to let them know that this object has changed. But its not certain what will happen if two requests for the lock come in at exactly the same time as they would both take the lock and send a notification off to the other clustered servers. I believe that there's no code to resolve this issue.
So for our deployment we've gone with disabling the cache for the nodestore altogether so that updates for locks and other metadata are written directly to the db. The content store also has its cache disabled right now as it seems that caching for both node and content stores is controlled from the encompassing <store> definition.
So far we think it will meet our particular performance requirements even with the caches disabled. A fully distributed cache (and so lock-safe) cache would be great but the question is would it be more performant than just writing directly to the db?... particularly when you consider that any negotiation for the lock that would need to occur between cluster caches would be over the network and subject to network latency. Anyone have any ideas as to how distributed caches actually perform in the real world?
Warwick
-----Original Message-----
From: Alessandro Apostoli [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 5:28 AM
To: Slide Users Mailing List
Subject: slide clustering support question
I have a couple questions about the clustering features of slide, suppose a scenario where you have a distributed replicated filesystem such as coda and a replicated db running on each node. Each node has the same data both on filesystem and db, the nodes are part of a big wan with links speed around 2 Mbit. The idea would be to use slide tx store for resources and revisions whilst using a jdbc store for properties, users, groups, roles and security
1) In such a scenario how would the locks on the filesystem behave, I guess that the transaction support in the commons.transaction.file package would be broken for there would be two or more instances of FileResourceManager accessing the same directory or am I missing something ?
2) For ideal clustering support would I be confined to the JDBC store?
3) If the Tx Store still works in this configuration how does slide solve the
above distributed transaction problem?
Alessandro
--------------------------------------------------------------------- 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]
-- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
