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