Alberto Valverde <[EMAIL PROTECTED]> writes: > > I don't think that it would turn out this way unless some sort of > "SELECT FOR UPDATE" statement is issued by the orm. The possibility > exists of two threads reading "5", in differerent transactions, and > commiting back "6", effectively counting only one visitor. Or maybe > throwing a non-serializable update error (if using postgres). > > The table should be locked from concurrent updates when the value is > read, something like: > > table.select(table.c.id==id, for_update=True) > > I'm not sure if you can do it with a mapper, better ask in the SA list.
If he's using PostgreSQL he can create a sequence and then just select the nextval() of it. It is safe to use it concurrently (in fact PG's SERIAL type is an automation to using an integer with a default of nextval() to a sequence) and it is incremented automatically. -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
