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: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Sent: Wednesday, July 23, 2008 5:21 PM To: [email protected] 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
<<inline: image001.jpg>>
<<inline: image002.jpg>>
