Advanced Database Features | 109requests to complete. When the file transfer completes, Mongrel processes that Rails
request all at once, only locking during the time the Rails code executes.
Themongrel_upload_progressgem hooks into Mongrel to provide a shared variable
that the multiple requests can use to communicate about the status of file uploads.
This variable is accessible to the Rails handler asMongrel::Uploads. A simple Rails
action (called via AJAX) callsMongrel::Uploads.check(upload_id)to check the sta-
tus and update the client.
Though all of this complication makes it possible to use just one Mongrel process,
most moderately trafficked applications will require multiple Mongrels. All actual
Rails requests are still serialized, so the number of requests being processed in Rails
concurrently is limited to the number of Mongrel processes. However, the shared-
memory solution used previously does not work with more than one Mongrel—each
Mongrel is a separate process and they have no shared memory.
The solution is to use DRb (Distributed Ruby). A background process is started as a
shared repository for upload status. Each upload handler notifies the background
process of its status via DRb as it receives blocks from the file. The Rails handlers can
then query the common backend for the status of any file, regardless of which Mon-
grel handled the original upload or status request.
The upload progress gem can be installed withgem install mongrel_upload_progress.A
sample Rails application illustrating how to use the gem is located athttp://svn.techno-
weenie.net/projects/mongrel_upload_progress/. The official Mongrel upload progress
documentation is available athttp://mongrel.rubyforge.org/docs/upload_progress.html.
Advanced Database Features
Among Rails programmers, advanced database features are often a point of conten-
tion. Some contend that constraints, triggers, and procedures are essential; some
shun them completely, saying that intelligence belongs in the application only. I am
sympathetic to the argument that all business logic belongs in the application; it is
nearly impossible to make agile changes to changing requirements when logic is split
between two locations. Still, I believe that constraints, triggers, and even stored pro-
cedures have their place in enterprise applications. In order to explain why, we’ll
have to examine a distinction that comes up often in relation to this debate: the dif-
ference between application and integration databases.
Application Versus Integration Databases
Martin Fowler differentiates between application databases and integration data-
bases.*The basic distinction is that an integration database is shared among many
applications, while an application database “belongs” to the one application using it.