Thanks very much for this. There are some very good points in here that have got me thinking.
At present I have only one Tomcat running and a small number of users (it's an intranet) but the complexity and resource requirements of the application set is growing. I don't have any experience of larger scale web systems so all suggestions are welcome. Saving the XML files was an initial step at caching things that I can control. I did play around with holding onto the (dom4j) Documents in the ServletContext but I was concerned that this would swallow all the memory unless I used some sort of soft-reference caching system. I posted a question about this to this list - but I never heard back - must have been too dull a question (or the wrong list)! I imagine spreading the apps over multiple Tomcats/machines would allow me to do more in-memory caching. Feels like this is a move toward Web Services - I don't know much about them. Thanks again for your response - I'd be interested in hearing any other pearls of wisdom. Chris > > > On Wed, Sep 29, 2004 at 06:27:13PM +0100, Chris Ward wrote: > : Only having to "release" one file is great, but I've hit a problem > : of my own making. My webapp writes various XML files to datestamped > : dir within the webapp <context>. When I deploy the WAR file I purge > : all these generated files. > : [snip] > : Should I use a different <context> to hold my data? > > That's one option; but another (likely more scalable) idea > would be to put files in a filesystem, where they belong. > > The idea is to setup a directory outside of the Tomcat > context path -- specify it in a properties file, or in a > context param, whatever -- and write the data there. > > As the system grows to support multiple Tomcat instances > spread across different machines, you could share the > filesystem via NFS (not pretty, but it works), stuff the docs > in a database (not pretty, but it works), or have the > mid-tier Tomcat instances push the data to another, internal > Tomcat setup that writes the files to a clustered/RAID'd fs. > > .... etc, etc, depending on how valuable these docs are and > how much this app grows. > > By not writing to your context, you can wrap everything up in > a WAR file and, better still, gain (a little) more security > by making the WAR file owned and served by two different user > accounts. > > -QM > > -- > > software -- http://www.brandxdev.net > tech news -- http://www.RoarNetworX.com > > > --------------------------------------------------------------------- > 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]
