Thanks Dan, that was what i was looking for, the discussion seems to have taken off in a slightly different tangent to my original question, but it is still good information to know, so thanks all for your input.
To give a little bit more background, the application is being designed so that it can be downloaded and run without any other dependencies (ie tomcat or jetty running single webapp with derby embedded). However, there is also an option for hosting it, therefore we started thinking about hosting a number of copies of the same webapp in the same tomcat - that's when we wanted to know if it is better then to have a single network server derby serving all the webapps. Thanks Ron Dan Scott wrote: > > Well, this seems like flamebait to me. The proof is in the Apache > Derby that exists right now: it has a small foot print, you can set it > up in Network Server mode, grant privileges to discrete users and > separate applications through the use of schemas. It seems to perform > quite well, although nobody to date has stepped up to fund an official > TPC-C or TPC-H benchmark (which shouldn't surprise anyone, as MySQL > and PostgreSQL haven't had official benchmarks set here either). But > the original poster's question was not about performance benchmarks or > competing with IDS, Oracle, or DB2; it was a simple question about > memory usage. > > To answer the original poster's question, Network Server mode is > undoubtedly more memory efficient if you're using it as a central > database for more than a couple of applications. The reason the > threshold is a couple of applications is that the Derby database > itself runs in one JVM, while the Network Server runs in a separate > JVM. Thus, your memory break-even point is effectively two > applications hosted in a single Network Server mode Derby database. > After that, you're saving yourself one JVM per application (subject, > of course, to some increasing memory overhead due to the number of > concurrent connections your Network Server may have to handle). > > In terms of separating your applications at a later date, I wouldn't > worry too much about that. Use schemas to separate your application > and you can pretty easily shift an application to point at another > database at any given time; just export the schema for the given > application, load it in the new database, and change your connection > string to hit the new database. > > Dan > > -- View this message in context: http://www.nabble.com/multiple-webapps-many-embedded-vs-single-network-tf2522906.html#a7071921 Sent from the Apache Derby Users mailing list archive at Nabble.com.
