Use of transactions

[César Bustíos Benites]

Hello, first, let me give you an idea of the problem I'm facing. This is a company with a fruit packaging plant, they use several printers for the barcodes they attach in fruit boxes, clamshells and pallets. There is a Django table that keeps track of the current number for each one (caja, clamshell and pallet):

They don't want to be holes in the middle, if the current number for a box is 00071799 then there must be boxes from 00000001 to 00071798.  These numbers are used as primary keys for the Caja, Clamshell and Pallet models. 

The printing process is using atomic transactions:

@transaction.atomic
def print_barcodes(request):
    tid = transaction.savepoint()
    # lot of code here
    if error:
       transaction.savepoint_rollback(tid)
    # ...
    return JsonResponse(response)
 

We are getting a lot of these:

_mysql_exceptions.IntegrityError: (1062, "Duplicate entry 'XXXXXXXXXX' for key 'PRIMARY'")

Which means we have a fault in the process or maybe we are improperly using transactions. Help will be much appreciated regarding the problem and the following questions:

1. If we print 10 boxes from 00000001 to 00000010 and say (exaggeratedly) each box takes 1 second to print. Then, another guy wants to print boxes while the first transaction is still active, will he get  00000011? Considering that the numbers are updated during the transaction.
2. Do transactions stack and lock the tables? 

Thanks a lot

[César Bustíos Benites]

Anyone? T_T

[Esau Rodriguez]

Hi,

Transactions are a different concept than locks. In few words a transaction means that the all the sentences within it are done or not done, but can't be half done (unless you have savepoints, and want to rollback to a particular point). The locks avoid other for making operations on the table or row which should prevent from race conditions as no one is allowed to do modifications or even reads until the operation finished. 

So the answer to to your first questions is no, if you are  using id generation from DB it would take the first free at the moment it runs.

I think the problem you have is that the id generation is outside database, and probably is based on what is on the DB when you start printing (would be nice if you put more code about id generations).

Regards,

Esau Rodriguez.

Anyone? T_T

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b43184ad-cc06-4244-aea8-624a325c3538%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Esaú Rodríguez
esa...@gmail.com

[César Bustíos Benites]

Hello! Thank you for answering. So if that's the case then what is happening is that (according to question 1) the second transaction is getting the same number as the first one and complaining with the IntegrityError while trying to save. Is that correct? 

[Esau Rodriguez]

Hi,

it's hard to say without seeing more code. In my mind right now is something like:

* First transaction start

** T1: It reads maximum from DB (lets say is 100)

** T1: It will create 101

** T1: It will create 102

* T2: Let say at this moment second transaction start

** T2: It reads maximum from DB (depending on how you implemented your transactions could be 100 or 102 if the transaction is the whole block or every print)

** T2: It tries to create 101 (or 103) if is 101 you get an integration error

** T1: It tries to create 103 (as T2 already wrote it) you get an integration error

Regards,

Esau Rodriguez. 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cdd5d1ae-4736-4fe3-9052-00eceaf044b4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Esaú Rodríguez
esa...@gmail.com