Thanks, I have indeed spent a lot of time looking at SELECT FOR UPDATE, but as far as I can tell that locks rows that have been selected. That is not helpful in this use case, in which the issue is rows not existing, and then later existing. Am I misunderstanding?
On May 27, 11:48 am, "A.M." <age...@themactionfaction.com> wrote: > On May 27, 2012, at 1:07 AM, Jeff wrote: > > > I have multiple processes accessing a table. All of these processes > > want to read a set of rows from the table, and if the rows are not > > present they will make a calculation and insert the rows themselves. > > The issue comes where process A does a query to see if the target set > > of rows is present in the table, and they're not, and then another > > starts calculating. While it's calculating, process B inserts the > > rows. Then process A inserts the rows, and now we have two copies of > > these sets of rows. Bad. > > You should look at "SELECT FOR UPDATE". > > http://docs.sqlalchemy.org/en/rel_0_7/orm/query.html?highlight=lockmo... > > Cheers, > M -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
