Thanks. That explanation is helpful.
On Aug 10, 8:49 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > 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- Hide quoted text - > > - Show quoted text -
