locker 0.3.1 → 0.3.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 26ef04b820465aabae3bae6882ce4e26c10903be
-  data.tar.gz: da0895652026efb9c039587b23f83a82e5e0f6f6
+  metadata.gz: 1623bce6a4448a47c0f7244284c37a68b40a9fb3
+  data.tar.gz: c4b81eada8d4cf229eda2854308da3f7a13d13d3
 SHA512:
-  metadata.gz: e22f69322a8b8a22ec6c05a011a2a2824aede763357f673f34e08dc6d43584c103b24ac780f1df56d812814ce3768c2aa2c2b098fc2014f9639ec65d6852da4f
-  data.tar.gz: 0ebb808afb8b0e6442c8b9f7ad3360bf9771e41a26f4156cc3b8973a21ce735d4be62edacabed4cb52d035972f4e69a0e6360534eae9314855f8f488e3b6cd9f
+  metadata.gz: eb8b6a9996aeacd61f13101c8c84d0becdddd62caaaa2672f926934fb2f7ea2c5c403d50ff8ceb756c321bf2d9d77eaac2bc4c81ef9fc66bb220e8fa135543e7
+  data.tar.gz: 127921d87034603b81452a88bf578913f5b6cdaac722fd9bb8f05b43ba16c6e7ab05eab3c395b1297f72b8f6f097b538623342c357d36e8be3ca1c8b7b5d6135

data/README.md

@@ -27,7 +27,7 @@ Suppose you have a process running on a server that continually performs a task.
 #### Code (lib/new_feed_checker.rb)
 
 ```ruby
-while true
+loop do
   FeedChecker.check_for_new_feeds
 end
 ```
@@ -49,7 +49,7 @@ This would work fantastic, so long as `FeedChecker.check_for_new_feeds` is safe
 ```ruby
 Locker.run("new-feed-checker") do # One server will get the lock
   # Only one server will get here
-  while true
+  loop do
     FeedChecker.check_for_new_feeds
   end
 end # Lock is released at this point
@@ -68,7 +68,7 @@ This is great! We've made sure that only one server can run the code at any give
 ```ruby
 Locker.run("new-feed-checker", :blocking => true) do
   # Only one server will get here at a time. The other server will patiently wait.
-  while true
+  loop do
     FeedChecker.check_for_new_feeds
   end
 end # Lock is released at this point
@@ -150,7 +150,7 @@ end
 In our use we've settled on a common pattern, one that lets us distribute the load of our processes between our application and/or utility servers while making sure we have no single point of failure. This means that no single server going down (except the database) will stop the code from executing. Continuing from the code above, we'll use the example of the RSS/Atom feed checker, `FeedChecker.check_for_new_feeds`. To improve on the previous examples, we'll make the code rotate among our servers, so over a long enough time period each server will have spent an equal amount of time running the task.
 
 ```ruby
-while true
+loop do
   Locker.run("new-feed-checker", :blocking => true) do
     FeedChecker.check_for_new_feeds
   end

data/lib/locker/advisory.rb

@@ -33,7 +33,7 @@ class Locker
       connection = ActiveRecord::Base.connection_pool.checkout
       connection.transaction :requires_new => true do
         while !get(connection) && @blocking
-          sleep 0.5
+          sleep 0.005
         end
 
         if @locked

data/lib/locker/version.rb

@@ -1,3 +1,3 @@
 class Locker
-  VERSION = "0.3.1"
+  VERSION = "0.3.2"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: locker
 version: !ruby/object:Gem::Version
-  version: 0.3.1
+  version: 0.3.2
 platform: ruby
 authors:
 - Nathan Sutton
@@ -9,7 +9,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-02-11 00:00:00.000000000 Z
+date: 2017-04-07 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -114,7 +114,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: locker
-rubygems_version: 2.4.6
+rubygems_version: 2.4.8
 signing_key: 
 specification_version: 4
 summary: Locker is a locking mechanism for limiting the concurrency of ruby code using