orm locks and transactions

A. Lock

mysql in the lock, does not prevent other users' queries, we will prevent other users of additions and deletions to the operation.

entries = Entry.objects.select_for_update (). filter ( author = request.user) # match all rows are locked until the end of the transaction 
select_for_update (nowait = False, skip_locked = False) # attention must be used in a transaction which 
at present, postgresql, oracle and mysql database back-end support select_for_update (). However, MySQL does not support the nowait and skip_locked parameters.

II. Transaction

1. Enable global

When the request came, Django will open a transaction before calling the view method. If the request is properly prepared and correctly returns the result, Django will commit the transaction. Otherwise, Django will roll back the transaction.

This feature is very simple to use, you only need to configure its entry ATOMIC_REQUESTS set to True.

= {DATABASES 
    'default': { 
        'ENGINE': 'django.db.backends.mysql', 
        'NAME': 'mxshop', 
        'the HOST': '127.0.0.1', 
        'PORT': '3306', 
        'the USER ':' the root ', 
        ' PASSWORD ':' 123 ', 
        ' the OPTIONS ': { 
            "init_command": "the SET default_storage_engine =' INNODB '", 
　　　　　　　#' init_command ': "the SET the sql_mode =' the STRICT_TRANS_TABLES '", # configure open strictly sql mode 
 
 
        } 
        "ATOMIC_REQUESTS": True, # Enable global affairs, is bound to a http request response throughout the process 
        "aUTOCOMMIT": False, # global cancel automatic submission, caution 
    } 
}

　　This approach is above all a unified sql http requests are placed in a corresponding transaction execution (either all succeed, or all else fails). Is global configuration, if you want to turn on the water for a http request (and then customize the transaction), you can use non_atomic_requests decorator, then he can not control the affairs

from django.db import transaction

@transaction.non_atomic_requests
def my_view(request):
    do_stuff()

@transaction.non_atomic_requests(using='other')
def my_other_view(request):
    do_stuff_on_the_other_database()

Use non_atomic_requests modification is not recommended

2. topical affairs

Atomicity is a property database transaction. Use atomic, we can create a block of code includes atomic. Upon completion of block normal operation, all the modifications are committed to the database. Conversely, if there is an exception, the changes will be rolled back.

Usage 1 : function to do the decorators to use

from django.db import transaction
 
@transaction.atomic
def viewfunc(request):
    # This code executes inside a transaction.
    do_stuff()

　　

2 Usage: used as context manager

django.db Import Transaction from 
DEF viewfunc (Request): 
    # This code Executes in autocommit the MODE (Django's default). 
    do_stuff () 

    with transaction.atomic (): # open transaction 
        . # This code Executes Inside A Transaction 
　　　　 entries It = Entry.objects .select_for_update (). filter (author = request.user) # will lock all rows that match until the end of the transaction 
        entries.update (xxx) # when there are two simultaneous users to access, query may be to the same result ( the equivalent of two threads), but after the incoming data will not perform more pruning operations until the end of the first transaction

 do_other_stuff()

 

only the operation of the database transaction layer for transaction management, transaction management can not be understood as a python operation