Thanks for such a clear and helpful response.  I'll begin the upgrade
migration immediately.  I noticed that a newer project does use InnoDB,
yet I don't see anything in settings.py which specifies the engine in
either project.  It's been a while but  the original project was built
with Dj 1.2 and I think it used XP while the newer one was built with
1.3 under Windows 7.

 

I wrote a little conversion script which seems to work and I notice that
MySQL 5.5 defaults to InnoDB.  Here's the trivial script if anyone can
use it.

 

import MySQLdb

Connection = MySQLdb.connect (db="mydb")

Cursor = Connection.cursor()

Cursor.execute('show tables') #test connection

tables = Cursor.fetchall()

for table in tables:

    t = table[0]

    if t in 'vlog allfields editlog user'.split(): continue  #these are
views

    print t,

    sql = 'ALTER TABLE %s ENGINE=INNODB' % t

    print Cursor.execute(sql)

 

 

From: django-users@googlegroups.com
[mailto:django-users@googlegroups.com] On Behalf Of Ian Clelland
Sent: Thursday, December 15, 2011 1:02 PM
To: django-users@googlegroups.com
Subject: Re: Django 1.2.1 strange problem

 

 

On Thu, Dec 15, 2011 at 5:56 AM, Sells, Fred
<fred.se...@adventistcare.org> wrote:

I've got an older app that's been running in production for about 2
years on RedHat 4, MySQL 5.0.77 with MyISAM tables, Django 1.2.1 and
Python 2.4.

 

This app is used heavily by internal users, which is a relatively light
load compared to public sites.  I actually use Flex for the client side
and save each field when the user changes it.

 

About once a month one field in particular will have its value cleared,
or perhaps the save operation did not complete before the next user
input hits the server.  I've searched my code for an unexpected
reference to this field name with no results.  As I understand it,
Django is single threaded so I don't know how this can happen.

 

The Django code itself is not multithreaded -- it spawns no threads of
its own -- but that doesn't mean that your setup is single-threaded.
That depends entirely on how your web server is configured. Every
production environment I have seen uses processes or threads to serve
multiple requests simultaneously, which means that multiple instances of
the Django code are running at any given time.

 

Django tries to be thread-safe, which is slightly different -- the code
is written such that multiple threads can co-exist without stomping all
over each other's data, at least at the Python level.

 

At the database level, things are different again. This is probably
where your problems are coming from. If your database doesn't support
isolation through transactions (if you're using MyISAM tables on MySQL,
basically), then you are susceptible to problems like this. Database
operations can and will be interleaved, depending on when and how your
web server decides to schedule its threads.

 

         

        Has anyone seen similar behavior?  I plan to upgrade next month
anyway, but could this be an artifact of the older Django or of MyISAM
tables?

 

I doubt that upgrading Django will solve anything, but I would recommend
upgrading your tables to InnoDB. The only reasons I know for sticking
with MyISAM are a requirement for speed over all else (including data
integrity), and to use the MySQL "full-text-search" feature.

 

          I'm not using transactions since I'm not an experienced DBA,
but should I?

 

Happily, Django will take care of all of this for you; you don't have to
be a DBA, or even think about transactions most of the time. As long as
your database supports it, Django will automatically isolate each
request in its own transaction. If the view returns a response, the
transaction will be committed to the database, and if the view raises
error, the transaction will be rolled back automatically. In almost
every case, this behaviour will be exactly what you want.




 

-- 
Regards,
Ian Clelland
<clell...@gmail.com>

-- 
You received this message because you are subscribed to the Google
Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to