On Mon, Nov 4, 2013 at 8:45 AM, Andrus Adamchik 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
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.