Ruby on Rails enterprise ready?
Jon Mountjoy's Blog |
November 22, 2005 3:52 AM
|
Comments (2)
As Bill mentions, one of the new languages on the horizon generating interest is Ruby. I've been learning Ruby (and Ruby on Rails) for the past few months, and I like it – a lot. The language and the Rails framework is used in production, on many thriving sites. So it came as a bit of a surprise when I read this thread on how Rails handles stale database connections. It looks like there was (is?) no support for handling stale database connections. Uh.
Now admittedly I'm used to a few luxuries in WebLogic Server land. For example, automatically recovering leaked connections, connection reservation handling and of course, stale connection handling. Oh, did I mention distributed transactions? :-) A summary of many of the options available in a connection pool can be found here.
I am not only surprised by the poor support for stale connections, but also by how they sought to rectify the situation. There were many well-intentioned stabs at fixing it - but nobody said "Hey, let's go look at how this is solved in real industry-ready solutions. For example, I wonder what WebLogic Server does, or let's go investigate Hibernate." The "how about doing this" sometimes works, but many folk have been through this already - they should not have to reinvent the wheel. I'm not the only one to think of this. Check out Jon Tirsen's post where he suggests, "an ActiveRecord connection that uses the Weblogic connection pools (with full 2pc support)," albeit in a more integrated system ;-) (Yet another approach, though less satisfactory for Ruby users IMO, is a great JRuby integration.)
Something else that's interesting is that issues like this are not stopping adoption of Rails. Companies like 37signals are forging ahead creating great solutions, deployed and live. Obviously Rails is "good enough" - its lack of many enterprise features, distributed transactions being another important one, doesn't prevent adoption. Perhaps 37signals do something funky with their database connection handling, or perhaps it just doesn't matter for the vast majority of applications out there. I suspect that the latter is closer to the truth.
In J2EE land we tend to focus on solving the difficult problems, instead of making the easy problems easier to code. This is one of the biggest lessons that J2EE can learn from Rails - productivity. It's why I'm so excited about the adoption of Spring on WebLogic Server. It's a step in the right direction with respect to productivity. There are far more people out there needing a simple solution to simple problems, than there are people needing complex solutions to every possible type of problem. In other words, I think Ruby, and Rails, target the long tail far more effectively than J2EE. Still, I wish for better database connection handling....
Technorati Tags: jruby, j2ee, ruby, ruby on rails, weblogic
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Very interesting post - thanks. It resonates with me, because as a long-time Java developer, I'm a little unsure of where to begin new web development for some very small and simple sites. The whole Java world here is such a dynamic sea of standards that may not be so great (JSP), and other solutions that are great (Velocity) but only cover one piece of the puzzle.
So for me personally, it looks like I'm going to use Zope - because it basically provides, out of the box, what EJB aims for; transactions, authentications, etc. etc. But it does it in a way that's fast to deploy. EJB 3 might be easy to use now - but right now I don't have time to learn *another* set of APIs and protocols...
Posted by: denk on November 23, 2005 at 3:46 PM
-
As a programmer, I'd go for some of the lightweight Java frameworks that give you everything you want, but with less pain. For example, the Spring Framework. This lets you mix and match best of breed technologies: you can use Velocity or JSF or JSP or .. if you like, in the the rendering of views. You can use transactions, even distributed tx if the app server you deploy to (such as WebLogic Server) supports them, and it has a security framework too.
Posted by: jonmountjoy on November 27, 2005 at 7:54 AM
|
