Question

The Tastypie documentation states that bundles keep Tastypie more thread-safe but does not explain how and under what conditions. I have looked through the code however am not experienced enough to wrap my head around it.

I am prototyping a game that has a round object (for each round of play) and multiple states for each round (for each player’s information for that round). Each player updates their own state with an answer to the rounds word-phrase. I need a mechanism that lazily creates the next round of play if it doesn’t already exist. I currently trigger that round creation when a player updates their state.

If multiple players update their state (see StateResource.obj_update()) at the same time then could their attempt to create the next round collide? I am thinking that this could happen if one obj_update call checks to see if the next round exists and tries to create a next round before a different obj_update finishes creating a next round. I would solve this with some type of mutex but I’m not sure if that’s necessary. I’m wondering if there is a Tastypie-way to solve this.

My code is as follows:

#models.py
class Round(models.Model):
    game_uid = models.CharField(max_length=75)
    word = models.CharField(max_length=75)
    players = models.ManyToManyField(User)
    next_round = models.OneToOneField('self',null=True,blank=True)

class PlayerRoundState(models.Model):
    player = models.ForeignKey(User)
    round = models.ForeignKey(Round)
    answer = models.CharField(max_length=75)

#api.py
class RoundResource(ModelResource):
    players = fields.ManyToManyField(UserResource, attribute='players',full=False)
    states = fields.ManyToManyField('wordgame.api.StateResource',
                                attribute='playerroundstate_set',
                                full=True)
    . . .
    def obj_create(self, bundle, request=None, **kwargs):
        bundle = super(RoundResource, self).obj_create(bundle, request,**kwargs)
        bundle.obj.word = choice(words) #Gets a random word from a list
        bundle.obj.round_number = 1
        bundle.obj.game_uid = bundle.obj.calc_guid() #Creates a unique ID for the game
        bundle.obj.save()
        return bundle

class StateResource(ModelResource):
    player = fields.ForeignKey(UserResource, 'player',full=False)
    round = fields.ForeignKey(RoundResource, 'round')
    . . . 
    def obj_update(self, bundle, request=None, skip_errors=False, **kwargs):
        bundle = super(StateResource, self).obj_update(bundle, request,
                                                   skip_errors, **kwargs)
        if bundle.obj.round.next_round is None:
            new_round = Round()
            new_round.word = choice(words)
            new_round.round_number = bundle.obj.round.round_number + 1
            new_round.game_uid = bundle.obj.round.game_uid
            new_round.save()
            for p in bundle.obj.round.players.all():
                new_round.players.add(p)
            new_round.save()
            bundle.obj.round.next_round = new_round
            bundle.obj.round.save()

        return bundle

Answer 1

I think this doesn’t have to do much with Tastypie.

The problem you’re describing is related to the ORM and the database rather. The issue is that both requests could create new Round() under some circumstances (if they could be served in parallel and switch at any time which is the case with gunicorn and gevent) and one would become stale.

Consider the following situation:

First request arrives, retrieves the current round and “sees” that there is no “next” round. So it performs:

new_round = Round()
new_round.word = choice(words)
new_round.round_number = bundle.obj.round.round_number + 1
new_round.game_uid = bundle.obj.round.game_uid
new_round.save()

In the meantime a second request comes and (assuming it is possible in your setup) processing switches to that second request. It also retrieves the current round, and it also “sees” there is no next round, so it creates one too (a second object for the same logical round).

Then the processing switches back to the first request which performs:

for p in bundle.obj.round.players.all():
    new_round.players.add(p)
new_round.save()
bundle.obj.round.next_round = new_round
bundle.obj.round.save()

So now there “is” the next round. First request is processed and everything looks nice.
But the second request has yet to finish, and it performs the very same operation, overwriting the current round object.

The result is that you have one stale instance (the Round created by the first request) and that the first group of players uses a different Round than the second group.

This leads to the inconsistent state in the database. So in such case your resource update method is NOT thread-safe.

One solution to this would be to use select_for_update for retrieving the current round from the database. See Django Docs. If you used that, the second and consecutive requests would wait until you modify the current round in first request and only then retrieve it from the database. The result would be that they would already “see” the next round and not attempt to create it. Of course you’d have to make sure that the whole update constitutes one transaction.

The way to “use” it would be to override obj_get() method in the StateResource resource and instead of:

base_object_list = self.get_object_list(request).filter(**kwargs)

use (haven’t tested):

base_object_list = self.get_object_list(request).select_for_update().filter(**kwargs)

Of course this is not the only solution but others would probably involve redesigning your application so this might just be less involving.