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 >> >
