Basically, a non-thread safe table design is one that relies on the programming code to calculate defaults based on other values in the database. A prime example is that web2py does not support autoincrement columns other than the automatic primary key of id. If you need a autoincrement column as well as your id field, you have to emulate this. So if your new records get their extra field calculated from the last record inserted into the database (refer to example insert query), what happens when two people hit the page within a short period of each other? Both end up getting the same last record back from the database, and both try to insert with the same calculated id, but if the field is unique, only one gets through, the other gets a nice fat juicy error page.
There are other database types that web2py does not support, and it is not wise to emulate them, just design your database without those types. Yes, you will lose CSRF and double submission protection. I do not know if anyone has ran any of the proposed tests yet. Its definitely on my todo list when I can find spare time. -- Thadeus On Tue, Aug 10, 2010 at 4:58 PM, Anthony <av201...@yahoo.com> wrote: > On Aug 9, 9:33 am, Thadeus Burgess <thade...@thadeusb.com> wrote: >> Just make sure to follow ALL of the web2py performance enhancements. >> >> * Compile the app >> * Sessions to database >> * Make sure all database tables are designed to be thread safe >> >> (ie: don't do things like this... db.table.insert(myid=db(db.table.id >> >> > 0).select(orderby=~db.table.myid, limitby=(0,1)).first().myid + 1)) > > Can you explain more about how to stay thread safe with database table > design? Is there a reference you can point to? Do any common web2py > conventions tend to violate thread safety? > >> Also you might want to consider only using >> form.accepts(request.vars)... when using sessions with forms can cause >> reliability issues, even if your sessions are in the database. > > But without using sessions with form.accepts, don't you lose the built- > in protection against CSRF and double submission? Are there easy > alternative methods to handle those issues? > > I notice this issue was discussed in [1], [2], and [3] and some tests > were proposed there. Have those tests been run or any further progress > been made on diagnosing/fixing the problem with failed requests? > > [1] http://groups.google.com/group/web2py/msg/29e17a9f37a4a78f > [2] http://groups.google.com/group/web2py/msg/f6aa101f5140dc55 > [3] http://groups.google.com/group/web2py/msg/cda63a88f3b71f94 > > Thanks. > > Anthony >
