> I've attached a proof of concept for how I've approached the "homegrown" > version of this in the past. a jobs table has two update passes - one to > atomically mark jobs as "in progress" by a certain procid, then the > transaction is released so that other processes can theoretically work on > other jobs. after each job is completed the corresponding row is marked > as "complete" (or failed) within a separate short transaction per row. > no long running transactions are used so that there is always room for > multiple processes to join in the work. Oftentimes you'll hear people > doing this with MySQL and dealing with "select...for update" to try to > lock the rows as they are selected within the transaction but that method > has never appealed to me. > > all that said, I'm sure my approach has issues that are not (or perhaps > are) readily apparent. if you want really failproof behavior without > much tinkering the off the shelf solutions are probably worth a look. >
Thank you.. I am looking at the code now. Having not done any threading or post "orm tutorial" SQL Alchemy programming, I am not sure what it all does. Quick questions: How doe this code handle transactions? Where in the code does it atomically assign a task to a worker without making a race condition? (Or does it?) Thank you, :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
