I saw that you can turn cache-items to false and it will only store the IDs in memory, but at the expense of paging, or at least more efficient paging. Is this true? I thought the docs said that to do paging it would have to grab all the objects again, then grab the subset of data you want.
In our particular instance, we have very large objects that are relatively unique across clients. Some objects will be shared, but most won't. Just trying to forecast how it will effect the server. Thanks, Geoff --- In flexcoders@yahoogroups.com, Jeff Vroom <[EMAIL PROTECTED]> wrote: > > That is basically how it works but only if you have auto-sync enabled=true and cache-items=true on your destination settings. The auto-sync feature requires that we maintain at least the identities of all objects managed on every client so that we know where to push changes. The goal here is that you don't have to worry about tracking that and can still easily keep clients in sync. Also, if two clients fetch an object with the same id, only one copy is cached. If you turn cache-items=false, we cache only the ids, not the items so we keep a lot less state around (though we do have to go back to the assembler more often so that is more load on the database). > > If you turn auto-sync off, the server maintains no state but the synchronization functionality would then only work if you enable "manual sync" - i.e. where your clients specify subscriptions they want to listen to and also can specify meta-data that is attached to all changes made. That meta-data is used to route changes to the right subscribed clients. > > Jeff > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey > Sent: Wednesday, July 23, 2008 5:21 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] LCDS Memory Usage > > > Looking in the LiveCycle Data Services ES Developer's Guide, page 190, > it states: > "By default, the Data Management Service caches items returned > from fill() and getItem() calls and uses cached items to implement > paging and to build object graphs on the server when implementing lazy > associations. This causes a complete copy of the managed state of all > active clients to be kept in each server's memory." > > Here's what I think that means. If I have 100 clients, and each > client has one managed collection that contains 100 items in it, then > there would be 10,000 copies residing in memory on the server(100 > objects for 100 users). > > Am I understanding this correctly? Does this seem inefficient? What > if those objects happened to be really big objects... I mean really > big. Seems like that would take up a lot of memory on the server. > > Has anyone come up against this in practice? > > Thanks, > Geoff >
