Permalink
Commits on Apr 2, 2013
  1. Prepare 0.4.4 release

    sferik committed Apr 2, 2013
Commits on Apr 1, 2013
  1. We no longer use lock_exclusively!

    albus522 authored and sferik committed Mar 28, 2013
Commits on Mar 2, 2013
  1. Prepare 0.4.3 release

    sferik committed Mar 2, 2013
  2. Add Coveralls badge [ci skip]

    sferik committed Mar 2, 2013
Commits on Mar 1, 2013
  1. Merge pull request #38 from gaslight/master

    sferik committed Mar 1, 2013
    Use more generic (and SQL Server compatible) locking in reserve
Commits on Feb 27, 2013
Commits on Feb 26, 2013
  1. Prep for release 0.4.2

    sferik committed Feb 26, 2013
Commits on Feb 25, 2013
  1. Merge pull request #37 from shiroginne/master

    sferik committed Feb 25, 2013
    Wrong UPDATE sql query for postgresql db
Commits on Feb 14, 2013
Commits on Feb 12, 2013
  1. Prep for release 0.4.1

    sferik committed Feb 12, 2013
  2. Possible fix for MySQL support

    scosman authored and sferik committed Feb 12, 2013
  3. Test against JRuby

    sferik committed Feb 12, 2013
Commits on Feb 10, 2013
  1. Prep for release 0.4.0

    sferik committed Feb 10, 2013
  2. No need to check for Rails 3

    sferik committed Feb 10, 2013
  3. Merge pull request #26 from rwz/master

    sferik committed Feb 10, 2013
    Removed rails 2 compatibility
  4. Merge pull request #29 from scosman/master

    sferik committed Feb 10, 2013
    Perf suggestion
Commits on Feb 6, 2013
  1. Don't test against JRuby

    sferik committed Feb 6, 2013
Commits on Jan 29, 2013
  1. Even faster for postgresql

    scosman committed Jan 29, 2013
Commits on Jan 26, 2013
  1. Test against Ruby 2.0.0

    sferik committed Jan 26, 2013
Commits on Jan 25, 2013
  1. Fix the way we fetch jobs to work better for a large number of workers.

    scosman committed Jan 25, 2013
    Instead of fetching 5 candidates at attempting to lock each one by one, just lock the next job in 1 query.
    
    Example of old system and 100 workers (worst but not uncommon case):
    1) 100 workers wake up and fetch 5 candidate jobs (they all get the same, or very similar set of 5 jobs), making a total of 100 SELECT calls
    2) they all try to lock the first job (only 1 of 99 succeeds). The failing workers try the next, making a total of roughly 500 UPDATE calls
    3) a total of 5 jobs get processed from about 600 database calls, and we restart the whole process
    
    New system:
    1) 100 workers wake up and fetch the next available job, each getting a single unique job (1 SELECT and 1 UPDATE call each).
    2) a total of 100 jobs are processed with exactly 200 SQL calls
    
    I've also included an example to make it all work in 1 call, avoiding an extra round-trip. This requires custom SQL only tested with PostgreSQL
Commits on Dec 26, 2012
  1. Removed rails2 compatibility

    rwz committed Dec 26, 2012
Commits on Nov 29, 2012
  1. Fixed typo

    albus522 committed Nov 29, 2012
Commits on Nov 28, 2012
  1. Allow Rubinius failures

    sferik committed Nov 27, 2012