Hi...
thanks this was closer to me giving in...but I'll just write out your example in pseudoness, Use your mind's version of Thread to simulate this example... dave1 and dave2 1) dave1.save 1) dave2.save 2) transaction is started and dave1's state recorded for later 2) transaction is started and dave2's state recorded for later 3) dave1 is found to be valid but some process is stuck in IO and slows down] 3) dave2 is found to be valid and continues to save 4) dave1 waits 4) dave2 commits the save 5) dave1 saves fine unless an Exception is raised from the DB (or anywhere) 5) dave2 sulks you're case would still fail under the current implimentation, unless you had placed some sort of restriction onto the column within your database itself which could cause the DB adaptor to raise during commit (5) .... the active record validations are all in Ruby-land they are only useful for the very instance they are called (3).....inside or outside of a transaction block..... hence the big lock. so... validations outside of the transactions? :) You're post did actually make me think of an improvement to the validation system... that could actually solve the issue above.... might make another post to suggest the idea. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
