IMAP Gateway: UIDNEXT management in transactional objects
Bug #364503 reported by
Andreas Hügel
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenMapi.org |
New
|
Undecided
|
Unassigned | ||
Bug Description
UIDnext is currently managed as a Property on the respective folder. As folders are no transactional objects, they will be prone to race conditions, when the uidnext is updated by two or more clients simultaneously. One should rework the UIDNEXT management, by creating a specific folder in the IMAP-invisible area and create a message for each of the folders, that is being IMAP-Enabled. These messages are transactional, so we have better control for simultaneous action. Key is the saveChanges method, which should return an error, if another mapi client has done changes to the object.
Revision history for this message
| Andreas Hügel (andreas-huegel) wrote | #1 |
To post a comment you must log in.
* instead of a separate folder we will save the properties in a message that is stored as associated message to the folder we are storing the uidnext/uidvalidity for.
o catch MAPI_E_
o Test muss Lesen der aktuellen Werte und Schreiben der neuen Werte trennen. Im FolderHelper sind diese Funktionen getrennt zu implementieren und in einer übergeordneten Methode aufzurufen. Die Übergeordnete Methode muss die oben beschrieben eFehlerbehandlung durchführen. Der Test kopiert die Übergeordnete Methode und schiebt zwischen 1. und 2. Schritt das Erhöhen der uidnext auf einem separaten FolderHelper ein.