Answers inline:
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Glass Sent: Wednesday, November 07, 2007 1:54 PM To: [email protected] Subject: [flexcoders] Re: FDS ManualSync and AS [Managed] Metadata --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "jeffjvroom" <[EMAIL PROTECTED]> wrote: > > But the assembler doesn't know what fills are active, either. > > Or am I missing something? The assembler can keep track of a > > client's initial use of a fill (by saving the fillParams argument > > to the assembler's fill method), but can the assembler get > > notification when the fill is no longer being used (e.g., when > > the client goes away)? > > Yes, this is the case. The auto sync mechanism is what keeps track > of which fills clients are looking at specifically. You would have > to duplicate this logic and it is not trivial. To solve this > generally is a bit tricky - you need to watch when fills are made, > associate them with a session and remove that when the session > expires. It's a little worse than that, because you could have multiple sessions using the same fill, right? So you would need to keep track of which sessions reference a fill and only remove the fill when the last session had closed. Yes, that is basically what we do to implement auto-sync. I imagine that clustering only adds another set of problems on top of this too. Is there an example of using manual sync in a clustered environment somewhere? In the clustered case, each server needs to model only the fills managed by clients connected to that cluster. You do need to process all changes on all servers though which means broadcasting those changes throughout the cluster. In this case, I'm not sure how you are detecting that the collection changed in the first place but if you detect it on all servers in the cluster, it is pretty easy. You just use the DataServiceTransaction api and you can set the "sendMessagesToPeers" flag to false for the transaction. Each server will then push its changes only to those clients connected to that server. Ordinarily with the "refresh fill" mechanism, we route all changes such as 'create' and 'updates' to all servers in the cluster and then each server refreshes the fills for clients managed on that server. That process detects the changes to the collections and pushes the update collection message only to its connected clients. > > In my application, the fills have a sort value, meaning > > that the new item could be in different positions in > > different fills anyway, so what I think the client should > > do is to just start the fill over again when an item is > > created. How would the assembler notify the client that > > it should do that? (That is, how do I get something > > similar to a refreshFill method returning EXECUTE_FILL > > in the auto-sync case?) > > Again, we just don't have a great way to "refresh" an entire > sequence when auto sync is false. It sounds like you really > need the auto-sync=true with the "paged fill" support. Desperately :-) What I'm thinking of doing is have the new item added at position 0, and have the client check, when an item is inserted at position 0, if the item is "less than or equal to" (according to the sort being used) the item in position 1. If it's not, the client would just call the fill again to get the new item in its proper position. Does that make sense? Yes, that seems like it would be a reasonable workaround for this missing feature. You also could just use the pub/sub stuff by itself to subscribe to "refresh collection" messages and have the client refresh the fill when it receives the message. Either way, it is not the most efficient way to refresh a large rapidly changing collection but probably would work fine as long as the collections do not change too frequently. Jeff
