> For example, on the application I am working on, we changed a > screen that accessed a large amount of data. The time to draw > that screen changed from over 10 minutes (we killed it after > that, and are not sure how long it would have run unchecked) > to under one. In the case of smaller sets of data, we went > from several minutes to sub-second responses.
Ok :-) Our requirements was to have read (select) time under 10 ms, and insert/update times on about 20-30 ms. We have very plain data: userId | key | value, which is organized in virtual pages, like there are about 500 different keys, but you are requesting a page of 50 keys at time (same for updating). Second requirement: Hot-Standby-DB, meaning one reader, two writers and switch to second db, on failure, but also for maintenance. Third requirement: No cross connections between tables. There is a table user with same userId as in the above table somewhere, but they are not connected at DB level (they are connected on the service level, but the DB shoudn't know anything about it). This is required to make the whole app scalaable. Clustering DBs is a suicide, so we can reach more scalability by moving different db_instances( and therefore different tables) to many hardware machines, which is better, as spliting a table across multiple machines. As far as we tested it, there was no chance for it with hibernate. I also seriously doubt, it can be made with iBatis (maybe I'm wrong?) But to be true, I don't see _any_ usage for hibernate. If my model is simple, I don't need hibernate. If my model is complex, I take a OODB which is faster and better then. So where is the place for hibernate? Regards Leon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
