Hia, I'm still not in the scalability phase, someone else might help you better than me. For scalability you can deploy slide in JBoss for example (is JBoss scalable?). Also, slide's default server, Tomcat, is somewhat scalable as it supports clustering. The problem is with slide application, witch, if I remember correctly, has a problem related with a global cache that might be troublesome in a cluster environment. Maybe your company programming gurus could contribute for this problem ;)
Also, you can set up a JDBC connection to an ORACLE or SQL Server instances, witch might themselves be clustered (you can also create a J2EE DataSource to access the database). Perhaps you could have independent slide instances, all connected to the same clustered DB, having this way have a semi-scalable environment through the database features. The problem with this approach is the locking of a resource, witch could be opened by different slide instances at same time. Anyway, perhaps this shouldn't be a problem if your clients just need to read files. If they need to write concurrently, perhaps it's best to scrap this approach. Hope this helps, Miguel _____ Hi I am currently working on a project that utilises the Slide Kernal to provide a content management API. In order to provide management with a degree of confidence I need to confirm the scalability of the Slide platform. Can anyone out there provide details of existing application that support large numbers of simultaneous users (i.e. several thousand) ? Most of the access will be read-only but there will be relatively active forums which will be stored in a Slide repository. Any details of configuration to support a large audience (e.g. when to use RDBMS rather than file store etc) will be v useful. The application will be delivered as a clustered application, are there any issues with having multiple instances of the Domain object (i.e. one per JVM) access the same physical repository (i.e. are there issues of local caching, locking or transaction management). Any information will be gratefully received. Thanks Andy Bowes --------------------------------------------------------------------- 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]
