That said, I do know a lot of people who choose iBATIS even when they are starting from scratch.
However, modern best practice suggests that we should be caching as high up in our application layers as possible anyway. In other words, performance benefits gained by caching are greater at the presentation tier than they are at the persistence tier, and we probably shouldn't cache things twice. Therefore, I'd suggest caching at the web tier almost exclusively, and writing business specific caches at your logic/service layer on a case-by-case basis. This allows the database to do its job without introducing the complexities of a clustered caching solution.
trying to play the piano wearing mittens
It turned out to be quicker and easier for me to use straight-up JDBC. I'll think I'll be giving iBATIS a shot in my next DB-centric project.
The book is Java focused.
Another note is that we have .NET and Ruby implementations of iBATIS.
If so, do you think it's easier to handle than Entity Beans or Hibernate.
I have heard from our users that iBATIS is easier to learn.