[ckan-dev] potential lost resource in case of 2 simultaneous requests ?
Alex Gartner
alexandru.gartner+ckan at gmail.com
Fri Jun 30 22:59:07 UTC 2017
Hello,
I'm wondering if the fact that resource_create() ( and similarly
resource_update() ) does a package_show()
<https://github.com/OCHA-DAP/hdx-ckan/blob/dev/ckan/logic/action/create.py#L285>
followed later by a package_update()
<https://github.com/OCHA-DAP/hdx-ckan/blob/dev/ckan/logic/action/create.py#L302>
can potentially lead to a lost resource in some special cases.
Since postgres uses by default "read committed" transaction isolation I
think the following could happen:
2 almost simultaneous requests (R1, R2) come to the API and are dealt with
by different processes/threads. Both are modifying dataset *D which already
has one resource (resource1)*
TIMELINE
1. (R1) starts *resource_create*(resource2) on dataset D
2. (R2) starts *resource_update*(resource1) on dataset D
3. (R2) does package_show(D) => *gets D with just resource1*
4. (R2) changes resource1 in D
5. (R1) does package_show(D) => gets D with resource1
6. (R1) adds resource2 to D => D.resources = [resource1, resource2]
7. (R1) does package_update(D)
8. (R1) resource_create() finishes, everything is committed
successfully to the db => D has 2 resources in the db
9. (R2) does package_update(D) - please note that here D only has one
resource as read in step 3
10. (R2) resource_update() finishes, everything is committed
successfully to the db => D has just resource1 (resource2 disappears)
Question: is this something that seems possible ? I reproduced this locally
on a slightly modified CKAN running paster but that could also mean that I
have something misconfigured or changed. Before starting to think about
strategies for avoiding this scenario (like a different transaction
isolation) is there some mechanism in CKAN that would prevent this ? Did
anyone stumble onto such an issue ?
Thank you,
Alex Gartner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20170701/85900222/attachment-0002.html>
More information about the ckan-dev
mailing list