[ANN] NeverBlock support for ActiveRecord

[Muhammad Ali]

I gladly announce the first release of the NeverBlock PostgreSQL adapter
for ActiveRecord.

The new adapter enables ActiveRecord to perform queries in parallel even
in a single threaded Ruby1.9 application.

Benchmarking is showing very good results so far.

Read about it here:

http://oldmoe.blogspot.com/2008/08/activerecord-meets-neverblock.html

The official announcement with sample code and installation link:

http://www.espace.com.eg/neverblock...erecord-concurrent-db-access-without-threads/

For more info regarding NeverBlock itself:

http://www.espace.com.eg/neverblock

regards

oldmoe
www.espace.com.eg
oldmoe.blogspot.com

 

[Erik Hollensbe]

I gladly announce the first release of the NeverBlock PostgreSQL adapter
for ActiveRecord.

The new adapter enables ActiveRecord to perform queries in parallel even
in a single threaded Ruby1.9 application.

How does this differ from libpq's (and, by association, the pg driver's)
native support for this?

-Erik

 

[Muhammad Ali]

How does this differ from libpq's (and, by association, the pg driver's)
native support for this?

It builds on top of pg's async interfaces. But allows you to use them in
a semi transparent manner. Your code will look like usual (i.e. no
callbacks for processing results), thanks to Ruby1.9 Fibers.

The async facilities currently found in pg require that you send the
query, poll on the socket and may be run a call back after the data
arrives

With NeverBlock you are able to write:

@user = User.findfirst)
@user_favorite_hobbies = @user.hobbies.findconditions=>["favorite =
true"])

NeverBlock will be doing the fiber pause/resume for you in the
background.

regards

oldmoe
www.espace.com.eg
oldmoe.blogspot.com

 

[Erik Hollensbe]

It builds on top of pg's async interfaces. But allows you to use them in
a semi transparent manner. Your code will look like usual (i.e. no
callbacks for processing results), thanks to Ruby1.9 Fibers.

Wow, very cool!

-Erik

 

[Roger Pack]

How does this differ from libpq's (and, by association, the pg driver's)

native support for this?

-Erik

As far as I can tell, it uses libpq's drivers but in a 'reactor' way to
remain single threaded while handling multiple requests. It blocks the
request's fiber while that request is waiting for the database, and
resumes it when the query returns. So it's basically libpg +
concurrency without threads. This has potential to be more scalable
than using threads, at least I hope so.

-=R