What does the "thread safety" of sequel actually mean?
The following code has two threads write to a sqlite database inside
transactions, but the db gets locked in the middle of the first thread's
transaction, and then neither thread can proceed. Aren't transactions
atomic wrt ruby threads?
Wrapping the transaction in mutex.synchronize avoids the problem.
require 'sequel'
db = Sequel.sqlite '/tmp/foo.sqlite', :timeout => 1_000
db.drop_table :t if db.table_exists? :t
db.create_table :t do
text :name
end
t = db[:t]
threads = [0,1].map do |i|
Thread.new do
begin
db.transaction do
t << {:name => "fred #{i}"}
sleep 0.5
t << {:name => "wilma #{i}"}
end
rescue Sequel::DatabaseError => ex
puts "retrying in thread #{i} due to #{ex.inspect}"
retry
end
end
end
threads.each {|th| th.join}
__END__
Output:
retrying in thread 1 due to #<Sequel::DatabaseError:
SQLite3::BusyException: database is locked>
retrying in thread 1 due to #<Sequel::DatabaseError:
SQLite3::BusyException: database is locked>
retrying in thread 1 due to #<Sequel::DatabaseError:
SQLite3::BusyException: database is locked>
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" 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/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
