« Return to Thread: [RFC] drop plugin batch_commit for 0.40?

Re: [RFC] drop plugin batch_commit for 0.40?

by Michael Bell :: Rate this Message:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Gollub wrote:

> On Wednesday 08 April 2009 02:38:30 pm Michael Bell wrote:
>> Michael Bell wrote:
>>> The SyncML mapping is an open issue.
>>>
>>> SyncML/OMA DS clients can send a mapping after the changes from a server
>>> were received. These mappings are first available after the changes are
>>> committed. OpenSync is today not able to handle this after a change is
>>> already committed.
>
> That's wrong. Plugins can change the Mapping ID for this particular peer after
> it got commit to the peer.
>
> Example:
>
> - commit() call with change UID: 00001
> - plugin calls protocl specific code to commit change to peer
> - plugins retrieves the new ID of the change which got just committed. ID: 123
> - plugin now needs to call osync_changet_set_uid(change, "123");
> - then the commit function ends with osync_context_report_success()
>
> With the context reply (osync_context_report_sucess()) an internal function
> get called which reports the new UID to the internal mapping table.

The problem is that if you do SyncML this way then you run into a dead
lock after five commit() calls. "Committed changes" in my first mail
means that osync_context_report_success was called on the context of the
commit callback (of the plugin API). The pendingLimit stops the IPC
queue after five unreplied changes.

commit() is called for the UID 00001 to 00005 but no SyncML message is
perhaps send and so no map can be received but the IPC queue blocks in
this situation because five messages wait for a reply.

>> I could write some code for the SyncML plugin which writes the SyncML
>> mappings to the state_db of the sink because they are too late for the
>> changes.
>
> I really don't want to see that plugins reinvent the wheel and write their own
> mapping table. And reverting such temp. solution might cost more time to
> revert then actually find a final solution.

I don't want to do this. Please see my other RFC. The dead lock issue is
a fact.

Best regards

Michael
- --
___________________________________________________________________

Michael Bell Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice
Fax: +49 (0)30-2093 2704 Unter den Linden 6
michael.bell@... D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ5HDD2L0ZGCAwWqsRAi1tAJ4mlmdRCmlMscrZEnnXxzcQJNCo2gCg6Jyi
2Qgg+ueQ0XB04142ukH/GNM=
=Ztd9
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

« Return to Thread: [RFC] drop plugin batch_commit for 0.40?