Yes, the configuration as you have noted is what we are using. We aren't using the sequence store so by default the server was using a property in the properties table to implement a sequence. To reduce DB contention on the properties table we converted the DB2 adapter into a sequence store and used a DB2 sequence instead.
We aren't having any issues with sharing locks on the NFS mount. That may be because of the type of load that we have on it so you may want to check whether the XML descriptor lockstore works for your configuration. In any case you can always return to using the DB as the lockstore as well as nodestore its just that we tended to have a lot of contention on the DB tables because we are using external transactions. If you don't use them there will probably be very little contention on your tables and so you won't have to look for an alternative place to store locks as we have. Warwick > -----Original Message----- > From: Tony [mailto:[EMAIL PROTECTED] > Sent: Monday, November 21, 2005 2:20 PM > To: Slide Users Mailing List > Subject: Re: clustering questions > > > Going back to your configuration you have.. > 1) All workpaths on local disk > 2) The locks and content (rootpath) are on a shared drive > (NFS or similar?) > 3) The nodes are in a DB. Is the sequenceStorem securityStore > and the revisiondescriptor(s)store in a DB too? > > Are there issues with having the locks on a shared drive? I > know this is not recommended for mod_dav. > > > > > On 11/19/05, Warwick Burrows <[EMAIL PROTECTED]> wrote: > > > > > > Hey Tony, > > > > Yes the work dir I was referring to is set using the > workpath variable > > which is needed for the transactional file stores. Eg. the > stanard tx > > file store and the XML file descriptor file store. > > > > Warwick > > > > > > -----Original Message----- > > > From: Tony [mailto:[EMAIL PROTECTED] > > > Sent: Friday, November 18, 2005 12:27 PM > > > To: Slide Users Mailing List > > > Subject: Re: clustering questions > > > > > > > > > On 11/18/05, Warwick Burrows <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Answers below: > > > > > > > > > -----Original Message----- > > > > > From: Tony Tomcat [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, November 17, 2005 7:50 PM > > > > > To: [email protected] > > > > > Subject: clustering questions > > > > > > > > > > > > > > > I'm in the process of researching the best way to > build a WebDAV > > > > > system for a large user base. Because the storage is > > > still up in the > > > > > air and file versioning is desired Slide seems like a > > > natural fit. I > > > > > know very little about Slide or WebDAV but I'm familiar > > > with Tomcat > > > > > and HTTP. > > > > > > > > > > Because I am building a system for a large user base I would > > > > > need several tomcat instances and it sounds like the 2.1 > > > > > clustering support is what I need but from previous J2EE > > > > > experience > > > I know that > > > > > clustering usually involves pinning a user to a specific > > > instance of > > > > > Tomcat. Is this required in Slide? > > > > > > > > If you're not using external transactions then I don't > > > think you will > > > > need to pin your user to a particular tomcat. External > > > > transactions are managed using the Slide WebDAV client > currently > > > > via the startTransaction(), commitTransaction() and > > > > abortTransaction() methods. They are a means for you to manage > > > > synchronization in your between changes you make in Slide and > > > > those you make in your own separate app storage. External > > > > transactions require "sticky > > > sessions" > > > > because once a tx is started on a machine you can't continue or > > > > complete it on another server because the tx context is > > > stored within > > > > the running app and there is no means to transfer this > knowledge > > > > to another cluster member. > > > > > > > > Now as for Slide server sessions... I don't know as I have > > > a different > > > > configuration where the session on the Slide server is not > > > significant > > > > to authenticating/authorizing the user etc. But even if you > > > do want to > > > > maintain the session then both Jboss and Tomcat 5 have > their own > > > > clustering implementation that allows you to share user > sessions > > > > amongst clustered servers. > > > > > > > > > > > > > In the ideal world users hitting my system would all come > > > though a > > > > > switch at my.domain.com <http://my.domain.com> > > > > > <http://my.domain.com> > > > < > > > > http://my.domain.com>. > > > > > Incoming requests would then be > > > > > routed randomly to the various tomcat servers in my system. 2 > > > > > subsequent requests from the same user would likely hit > > > > > different tomcat servers. Does Slide Clustering support this? > > > > > > > > Yes. From my experience it does. Even when I have external > > > > transactions enabled it would work part of the time. It > > > wasn't until I > > > > put significant load on the system (and it tried to > load balance > > > > during an external transaction) did I see problems. > > > > > > > > > Also. Can my locks and content be on different > storage systems? > > > > > I suspect for clustering to work well I would have user > > > files on NFS > > > > > (or similar) and the locks would be in a shared database. > > > or maybe > > > > > I'm just crazy. ;-) > > > > > > > > You will need to share your content and lock stores between all > > > > servers in some way. Your tx file system "work" dirs > should not be > > > > shared as that's where temporary transaction information is > > > stored. We > > > > use a tx file store and DB2 node store and we were keeping > > > our locks > > > > in the DB to share them between servers. But due to the load on > > > > the lock table (which creates both normal and > transaction locks) > > > > the DB was performing badly (-911 errors). > > > > > > > > > ok.. dumb question.. What is the work dir? Is that what > is specified > > > in the workpath? I've been looking for an explaination of the > > > workpath on the slide site and wiki with no luck.. Once I get my > > > hands around this I'll try to help out with the documentation. ;-) > > > > > > > > > > > > So we kept the DB as our node store but reconfigured the > lockstore > > > to be > > > > a tx XML descriptor store. I also found that it was safer > > > to configure > > > > the "work" dirs for the tx file stores so that they are not > > > > shared. This is because slide will rollback any uncompleted txs > > > when it starts > > > > so if one machine in the cluster goes down and comes back > > > it may try > > > > to rollback any currently running txs from other cluster > > > members that > > > > it finds in the shared work dirs. > > > > > > > > > > > > > Thanks in advance for any information! > > > > > Tony > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > > 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]
