Working With Rails

Hi Reinhart,

A Thread is a totally different concept to a Transaction.

You might get better answers to your questions if you post each question separately.

Jon’s (as usual) right.

Regarding question #4: It could be that I misunderstand what you’re talking about, but Rails acutally DOES use a timestamp for every log entry. Just take a look at the following log entry:

Processing OrdersController#create (for 86.59.96.10 at 2008-05-06 00:37:29) [POST]
...

The actual entry is quite a bit longer (especially if you have set the config.log_level to :debug rather than :info, but every log entry always starts with the controller (OrdersController) and action (#create) plus the IP address that issued the request (86…..), the timestamp (2008-...) and the request method (POST).

HTH

Thank you Jon and Kofler, I have done for question in number 4 by adding it at the last line of environment.rb

class Logger def format_message(severity, timestamp, progname, msg) ”#{Time.now.to_yaml} (#{$$}) #{msg}\n” end
end

But i still struggle for question number 3, a few article suggested to use Thread in preventing DeadLock, but they no give detail how to implement it. maybe you guys will be generous to help me and explain it.

Thank you,
Reinhart

What are you doing to get a deadlock? I’ve written two fairly big sites in Rails and I’ve never had an ActiveRecord deadlock.
It might help if you showed us some code, and a stack trace if you’re getting an exception thrown.

Are you connecting to more than one database?

Threads are useful for allowing a program to continue running if a deadlock or blocking situation occurs, but only if you structure the program properly. If you have a need for access to resources that may block then you may want to run the code that performs the access as a thread. But this is only necessary in programs where you need to run other parts of the program while the thread is waiting for access. Threads are good to use in situations where there are numerous simultaneous attempts to access a resource where the access could block.

Using threads requires an understanding of how to synchronize them. The level of sophistication that goes into synchronization depends on what you are doing, but it can get pretty complex. You can definitely gain a nice performance improvement using threads in a simple manner, depending on what you are doing in your program. But you will need to structure your program a little differently to use threads.

Here is my code Jon that is using pesimistic :lock => true
http://pastie.org/195869

and here is active record that contain lock:
http://pastie.org/195875

And here is error log :
http://pastie.org/195865

in error lock, for line 52-55, Transaction 2 can grant exclusive lock, whereas the transaction 1 is already granted lock and no release lock, how i can make lock is released after commit? and why lock for transaction 2 can be granted while Transaction 1 is not realeased and not commiting transaction?

Thank You very much
Reinhart

Hi,

I don’t understand the language so I’m just going by what the code is doing…

You begin a transaction on line 12, but you do a massive amount of work during the transaction – including sleeping for 30 seconds (line 29).

You acquire the lock, then sleep for 30 seconds while still holding the lock. During that sleep, another thread tries to get the lock. It can’t, so it fails.

You have to minimise the chance of this happening by making the transaction as small as necessary.

You say “how can I make [sure] the lock is released after commit”? – in your code you sleep before the commit happens. The commit occurs at the “end” statement on line 39 (BTW indent your code properly, it will be easier to read :).

Do you really need the transaction to include the product lookup on lines 17-19? I think the transaction block could be made a lot smaller, and you should definitely get rid of the sleep statement.

To go back to your original question, if you really need a transaction for this code, then you shouldn’t be thinking about preventing a deadlock – you should be thinking about recovering gracefully from a deadlock. Either report the error to the user, or retry the action.

I am sorry because i forgot to translate my code in english, by the way, thank you for your suggestion, it was answered me for the last statement of yours. :D

Cheers,
Reinhart