> But we don't have to be scalable, do we? Most of the work requests will > be from a single user for the same set of data, so he will not ask for > more than one sync and even if he does, we wouldn't be able to do more > than one sync at a time. Got it. so currently we support only one sync session at a time and queue other requests. > Clearly modifying the configuration of an active session isn't possible, but > even just reading old session logs suffers from a race condition: > the number and content of old sessions can change as the current session > expires old logs. I learned from previous discussion that even a config reading request could also be queued for underlying data bases. Is it too strict? At least I often start a sync at the same time I'll query some config informations.
Cheers, Yongsheng -----Original Message----- From: Ohly, Patrick Sent: Tuesday, August 25, 2009 7:17 PM To: Zhu, Yongsheng Cc: SyncEvolution Subject: RE: [SyncEvolution] next generation syncevo-dbus-server On Tue, 2009-08-25 at 07:41 +0100, Zhu, Yongsheng wrote: > > It might be more complicated: different server configurations may > > access the same data, in which case locking just the configuration is not > > enough. We would also have to lock the underlying data bases. I expect > > this to get tricky quickly, which is why I suggested to implicitly > > serialize > > *all* kinds of accesses. > Yes, providing different kinds of accesses is a good way to improve > scalability. But we don't have to be scalable, do we? Most of the work requests will be from a single user for the same set of data, so he will not ask for more than one sync and even if he does, we wouldn't be able to do more than one sync at a time. > IMHO, besides, we'd better partition resources into many sub-parts and > each-part > has its own lock so that for exclusive locking, some race conditions could be > avoided, > though this could lead to be more complicated. I think we should design the API so that it supports concurrent operations, but not implement that at this point to avoid the complexity. > This covers about 'session' topic. As I know, we'll also cover dbus api for > sync server side > for direct sync, automatic sync, and others, according to your previous > discussion. > Will dbus-api design cover all of them by the end of this week? I have not been able to reach Jussi yet. I suppose we'll have to go ahead without him. I'll write down an API proposal, similar to the one I did for incoming connections, and then we can continue the discussion based on that. I don't intend to cover automatic syncs. It's part of the design and fits into the model that sync sessions can come into existence without any GUI having asked for them, but how this really works in practice is an entirely different problem (need config changes, daemons watching for changes, etc.). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
