> Just so it's clear, I'm not opposed to removing non-shared-cache as an > option. I just wanted to let you know why I was considering using it > since you asked.
Of course. Understood. And I appreciate this discussion. >> I will have to look into that. I thought when I was doing my testing >> of changing the qualifiers with a separate ServerRuntime that it used >> a separate database connection. Maybe it's just not configured to >> share the datasource by default. Yes, this depends on configuration of your stack. JNDIDataSourceFactory will result in a shared connection pool (provided by container). XMLPoolingDataSourceFactory will not. >> But if it's < 1Mb per runtime, then it's unlikely it will matter. >> Since my largest xml data map file is a 256K and contains 75 entities, >> I assumed that each runtime would also have to load a copy of that >> data into memory. Sorry, I missed that part. Copies of DataMap (or more precisely - EntityResolver) will use some memory. Though EntityResolver can be loaded once and shared between runtimes using a custom DataDomainProvider or something. Andrus On Nov 4, 2013, at 5:22 PM, Mike Kienenberger <[email protected]> wrote: > Just so it's clear, I'm not opposed to removing non-shared-cache as an > option. I just wanted to let you know why I was considering using it > since you asked. > > > On Mon, Nov 4, 2013 at 9:10 AM, Mike Kienenberger <[email protected]> wrote: >> On Mon, Nov 4, 2013 at 8:45 AM, Andrus Adamchik <[email protected]> >> wrote: >>>> Having separate ServerRuntimes would require separate connections to >>>> the database, correct? If so, that would not scale well. >>> >>> No. All of them can reuse a single shared DataSource. >> >> I will have to look into that. I thought when I was doing my testing >> of changing the qualifiers with a separate ServerRuntime that it used >> a separate database connection. Maybe it's just not configured to >> share the datasource by default. >> >> >>>> I'm guessing it would also use quite a bit more memory if each session >>>> had its own ServerRuntime, depending on the size of your data model. >>> >>> “Use shared cache” creates the most of the memory overhead. Memory overhead >>> of multiple ServerRuntimes (compared with unchecking "use shared cache”) is >>> only in keeping clones of various service singletons (factories, etc.). I >>> should probably try it out in profiler and see what the exact value is, but >>> my wild guess is < 1MB per runtime. >> >> You mean 'Unchecking “Use shared cache” creates the most of the memory >> overhead', right? >> >> I started to comment on this in my first response, but decided it >> didn't matter. There's little point in comparing it against the >> other memory since that memory use is going to be the same whether >> it's one or multiple ServerRuntimes, and will depend on the >> application. In my use case, the amount of database information >> pulled in is pretty small per session most of the time. Maybe one >> table row from five-to-ten tables and a few table rows from a couple >> of other tables. Less often a session might pull in a great deal >> more data from a lot more tables. >> >> But if it's < 1Mb per runtime, then it's unlikely it will matter. >> Since my largest xml data map file is a 256K and contains 75 entities, >> I assumed that each runtime would also have to load a copy of that >> data into memory. >
