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>. > > 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] > >
