> 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'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. Andrus On Nov 4, 2013, at 4:40 PM, Mike Kienenberger <[email protected]> wrote: > Having separate ServerRuntimes would require separate connections to > the database, correct? If so, that would not scale well. > > 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. > > > On Mon, Nov 4, 2013 at 8:29 AM, Andrus Adamchik <[email protected]> > wrote: >> Wonder if there’s any benefit here vs. just starting separate ServerRuntimes >> per session? >> >> On Nov 4, 2013, at 4:24 PM, Mike Kienenberger <[email protected]> wrote: >> >>> I was considering unchecking it to force every session of my web >>> application to work with its own set of records from the database. >>> >>> On Mon, Nov 4, 2013 at 2:16 AM, Aristedes Maniatis <[email protected]> >>> wrote: >>>> We experimented with that option and unticking it caused expected >>>> behaviour that was quite hard to understand. Particularly in how it >>>> inter-related to the object cache. Dima is the person who knows all the >>>> details of that experiment. >>>> >>>> I certainly remember thinking to myself "never uncheck that option". >>>> >>>> Ari >>>> >>>> >>>> >>>> On 4/11/2013 5:36pm, Andrus Adamchik wrote: >>>>> Hi everyone, >>>>> >>>>> I’ve been considering removing support for “Use Shared Cache” checkbox >>>>> from the Modeler and for the corresponding code in the framework. This is >>>>> about a strategy for a *snapshot* cache that is used to save a DB trip >>>>> when resolving to-one relationships or checking a previously committed >>>>> state of a modified object. The alternative (i.e. when it is unchecked, >>>>> and a per-context cache is used) is not very useful IMO and the need to >>>>> support both strategies results in lots of dirty code. >>>>> >>>>> Now I am wondering have anyone ever unchecked that checkbox, and if so, >>>>> what was the reason? >>>>> >>>>> Also if you have no idea what I am talking about, it also answers my >>>>> question :) >>>>> >>>>> Thanks, >>>>> Andrus >>>>> >>>> >>>> -- >>>> --------------------------> >>>> Aristedes Maniatis >>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>> >> >
