Hi All,
I had a bug in one project, that data get duplicated in the DB due to
multiple instances of the application (multiple thins) are accessing the
DB at the same time .. The typical mistake.
Problem fixed.
I just need to write a test code that covers the fixed bug.
I need to simulate the concurrent requests that can result in the
original bug. I thought of many ideas and decided to go with forking 2
or more processes (from within the test code) in which I issue a get
request to my controller-action.
Setup: MySQL DB, Rails 2.3.5, Ruby 1.9.1, Shoulda and FactoryGirl.
Unfortunately this test code doesn''t do the trick.
When I try to remove_connection before forking and then
establish_connection inside the children processes, I don''t find data
when asserting.
When trying to use the same connection among the parent process and its
children, I get into a total mess (due to concurrent access to the db
connection).
Sample errors from different runs:
The famous "MySQL has gone away"
Some other times it work perfectly!
"Mysql::Error: SAVEPOINT active_record_1 does not exist"
"undefined method all_hashes for nil:NilClass"
I know that I have so many issues to handle here: concurrency safety,
blocking DB adapter, the nature of the testing environment..etc
But, is there another approach to handle it?
What is the best practice of testing code for concurrency?
I know that u may need more details or code sample .. but I''m trying to
think of the concept itself.
Sorry for the long message.
Thanks
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
