There were several strategies attempted where I used to work (this was with Hibernate) so I'll share my ORM experience...
The first "strategy" was to cache the entire world. That was a really bad idea because the database was around 800GB in size, and used by multilpe systems - a Java-based system, and about a zillion AS/400-based RPG programs. Once our "architect" realized that this was a bad idea, *all* caching was removed. At that point, performance went in the crapper, becuase the way that the mapping was done, it was assuming that everything was always in memory...but since it was not, it went to load it. Now, this example is not that great, because it should have never happened. The database we were using was about 20 years old, had some denormalization for performance, and was difficult to change because of the number of RPG programs that used it. It also used triggers to implement much of the business logic. For all of those reasons, ORM was a really, really bad choice. ORM generally assumes that the application is the database, but this database was designed to be the application. That may need some clarification. This database was designed so that if someone did an update with SQL, all of the business logic would still be executed (hence the triggers). ORM tools expect that they and they alone update the database, and that all of the business logic is in the code. When things like triggers or other applications update other data, things get ugly fast. This dissonance in design made this application almost completely unusable. We ended up with one application in particular that took literally 10-15 *minutes* to load a web page. All for the sake of making the application database agnostic and writing less code. Once the users started showing up with torches and pitchforks, things started to change. We decided to start using the database as a database, not just an object repository. We rewrote the "10-15 minute" application with iBATIS and 2 stored procedures, and when we released it to test, we started getting calls from users that it was not getting the data from the database, because it didn't take long enough. It was working fine, but the time change was so dramatic that they thought it was broken. Really. After that, I have not stopped to look back. :-) Larry On 2/14/06, Troy J. Kelley <[EMAIL PROTECTED]> wrote: > Larry, > > Just a clarifying question: When you say "multiple apps that do not all > operate within the same JVM", what kind of ORM-specific problems are you > referring to? Are you assuming that with ORM you always try to keep a > complete object graph in memory? I would probably use a bit of a > different strategy in terms of how much of the object graph I load into > memory for any specific request when dealing with a large database. > > You're right - I don't think a rich object model precludes the use of > iBatis. I was only referring to our internal approach. > > Thanks for your reply, > > -Troy > > Troy J. Kelley > E-gineering, LLC > 10401 North Meridian Street | Suite 150 > Indianapolis, IN | 46290 | 317.616.3974 > www.e-gineering.com > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Larry Meadors > Sent: Monday, February 13, 2006 4:17 PM > To: [email protected] > Subject: Re: Does iBatis have a direct competitor? > > Interesting. > > My experience with ORM must be quite different from yours. > > I have seen some special cases where ORM might come in handy like > smaller projects where the database is only used by one application, > and would all fit into memory. > > In an enterprise application on the other hand, where the database is > in the 100s of GB range and shared by multiple applications that do > not all operate within the same JVM, I have had nothing but pain with > ORM. > > I am aware of no reason that a rich object model would preclude the > use of iBATIS. > > Larry > > > On 2/13/06, Troy J. Kelley <[EMAIL PROTECTED]> wrote: > > To save on some typing, I'll point to the blog entry that I just wrote > about this: > > > > http://jroller.com/page/tkelley?entry=does_ibatis_have_a_competitor > > > > Not that I *want* to find something other than iBatis... I've been > tasked with trying to find solutions that don't quite call for the ORMs > and I'm having a bit of difficulty finding some middle ground solutions > that are based on the concept of Data Mapping. Based on what I've read > and experimented with, I'll be content if I only have iBatis to choose > from :-) > > > > I'm new to the mailing list, so I want to use this first post to say > thanks to the iBatis team for their time and effort. You guys rule. > > > > -Troy > > > > Troy J. Kelley > > E-gineering, LLC > > 10401 North Meridian Street | Suite 150 > > Indianapolis, IN | 46290 | 317.616.3974 > > www.e-gineering.com > > > > >
