I posted a message over in the hibernate forums regarding how hibernate and ibatis handle caching:
It would be nice if some of the iBatis experts take a look at what I said there, because I have pointed out a couple scenarios where I think iBatis' caching can't do would I would like and I am wonder if hibernate can. I wondering if what I have said about the iBatis caching is true.
Do you have a *real* performance problem or do you not just like the fact that your cache gets blown away when Products are updated?
If the later then you may be worrying for noting. AFAICT, there will not be much of a difference retrieving item from cache with 10K Products and going to the db.
I just don't like the fact that the cache gets blown away. I am trying to decide which persistence framework I should use on my project and see this as a potential performance problem. I would rather go with a framework which I know has the flexibility in the caching so I don't have to build it with ibatis and end up redoing it with hibernate once I find out that blowing away the cache is a real problem. This is the only thing I don't like about iBatis and it is the only reason I am even looking at hibernate. Given other factors such as ibatis is simplier and I have successfully used iBatis in other projects I will probably just stick to iBatis. Just seeing what my options are.
Seeing as how we're an OSS project and all, please feel free to submit design ideas, patches or patterns for dealing with this.
The biggest challenge facing iBATIS caching is that iBATIS does not distinguish the primary keys in the database, nor does it implement the conccept of Object Identity. These are things that are needed for effective caching, and is something that ORMs will always do better.
We could implement PK and OID, but at the expense of simplicity and flexibility. If there was a way we could make it non-intrusive and maintain consistent semantics, then it might be something we can do...
Open to thoughts.
PS: You can simulate PK/OID caching with iBATIS, it's just requires a lot of manual set up of the cache models, which is not usually ideal.
>> PS: You can simulate PK/OID caching with
>> iBATIS, it's just requires a lot of manual set up
>> of the cache models, which is not usually ideal.
Please explain briefly how this may work.
Are you saying that it could be possible to obtain cached values from iBatis based on Primary Key Values or other OID values? If so, then I think this would be a great enhancement.
However, will it not be less complex to enhance so that it is possible for iBatis to simply return some unique value for a cached resultset back to the caller? The application can then do the necessary association itself? At least that way, I can, say associate cache key value "xyz" with primary key value "123". Maybe returning it in a bean value ???
(Ok, I'm dumb. Don't laugh!) :)
> I just don't like the fact that the cache gets blown
> away. I am trying to decide which persistence
> framework I should use on my project and see this
> as a potential performance problem.
From my experience, it takes LONGER to retrieve item from Hibernate cache with 3K+ items then to retrieve it from the database. I had to explicitly clear Hibernate's cache to force db call to get acceptable performance.
In other words, Ibatis approach to cache is very simple and generally works better with large number of items.
i have worked with level 2 cache in hibernate. it really sucks. Big time. it's simply flawed or full of bugs. In complex apps (400+ tables) with complex m-n relationshpis, the hibernate cache produce unexpected results combined with lazy loading. FORGET ABOUT HIBERNATE! I HAVE STRUGLLED WITH IT FOR 1 YEAR TO DECIDE TO GO WITH IBATIS. TOO BAD I HAVE WASTED MY TIME WITH HIBERNATE!
Hibernate Team say that Hibernate is better for complex applications. I think that if my legacy database has complex relations with composite id's, is better to work with iBATIS than with Hibernate. This is the principal reason because I'm working with iBATIS, and I feel very comfortable working with it.
I have worked with both Hibernate and Ibatis extensively but have spent more time with Hibernate. I have been successful and much prefer Hibernate for transaction oriented coding, which is where the cache really matters. If you have a procedural coding background, you will likely find that Hibernate is unintuitive and your applications/productivity will suffer with Hibernate and you will find Ibatis is a better fit. However, if you are comfortable writing object oriented programs you will likely get a productivity boost from Hibernate. You should certainly build tests along the way, which will help you evaluate performance and help keep you out of trouble as you play with different cache options.
No matter which option you choose, you have to configure your cache carefully and I would leave this step to the end. The cache you use can also have a major impact on performance. With Hibernate you have several implementations along with quite a few configuration options. Don't assume that lazy loading and cacheing will improve performance.
I hear the OO card played a lot in the iBATIS vs. [insert ORM product here] discussions.
I completely disagree.
Using iBATIS vs. Hibernate has VERY little to do with the object oriented nature of the application, and it has everything to do with the database design. That said, iBATIS is more flexible on both counts, as it can handle non-OO domain models, and "less than relational" databases. However, this doesn't mean that iBATIS is any less suitable for OO applications. In fact, iBATIS does a BETTER job of isolating an object oriented domain model from a really complex database. Hibernate simply cannot achieve this level of separation because by nature it maps classes to tables. There is very little separation or isolation with this approach. iBATIS has an extra layer of abstraction that ensures that the data model stays far, far away from your business domain model. In other words, it allows you to truly design an object oriented solution, without having to worry about how it will map to the database.
Hibernate has many advantages, but iBATIS is every bit as suitable for object oriented applications.
Here's a challenge:
JPetStore has what I would regard as a fairly appropriate business object model. The database was designed by Sun, and to make it a fair comparison I had to keep the existing design.
I would challenge you to replace the JPetStore persistence layer with Hibernate, without changing the business object model (i.e the domain package).
There are 9 domain objects, 7 DAOs, and 18 CRUD methods. iBATIS DAO supports Hibernate. If you decide to take me up on it, let me know so I can get you a copy of iBATIS 2.0.5 which has an improved Hibernate DAO template (will save you some typing).
Should be a snap.
I wasn't trying to play cards. I don't disagree that iBatis can be used to produce OO code only that as you say "it can handle non-OO domain models". I have found that programmers who write procedural code will make the strongest argument against Hibernate, which has not been designed to write procedural code.
The stock OO answer is to use DAOs. I find DAOs less productive and the tendency is to marry your objects to the implementation.
Both Hibernate and iBatis have strengths and weaknesses. My experience is that Hibernate is very productive on complex databases because I don't have to worry about the underlying structure while writing code -- your main work is in the model so you must have a good understanding of the options. iBatis is production for reporting or when stored procedures encapsulate your business logic.
I have looked at your pet store implementation and given some time will see what I can come up with. What do you think will cause problems with Hibernate? If I get some time I will see if I can do something with it but it is more likely that I will have the time to look at a part so it would be best to focus on the percieved problem areas.
Contrary on what some of the posts try to prove, Hibernate is NOT good for complex databases. We tried to work with Hibernate with a 400+ tables database.
All the operations with the DB are extremely slow via Hibernate. Think about it: with Hibernate you MUST configure cascading at startup. This means that you would NOT be able to control relationshpis b/w objects programatically. This means you will end up doing UNNECESSARY selects and updates when working with large object models.
All these problems can be AVOIDED by USING IBATIS!
I am working with Hibernate & iBatis together over a very large database both in size 100+ Gig with several hundred tables. I am not trying to convince you to use Hibernate but it is not true to say that you will do UNNECESSARY updates.
Hibernate maintains a dirty flag and will only update changed entities up or down the chain as you have defined. You control what is updated define relationships as regular or inverse and whether changes are cascaded. Changes can be maintained in the memory model and persisted on demand. This approach can be more efficient because several changes to a single object become a single SQL update operation, which lends itself to the OO approach.
OO is simply not mapping tables to classes IMO. In fact, there are many bad designed (you cannot create a new database in many projects) databases in which tables do NOT represent an "object" in OO design. So hibernate is not that flexible in practice.
The other pain with Hibernate is lazy loading. Again, this is set up in the xml and cannot be changed programatically and therefore is a source of developer headache, prone to errors and poor performance. When talking about lazy via J2EE/RMI it becomes almost unusable.
Unless the Hibernate team improves flexibility/ease of use/ Hibernate is just a pain.
As a totally biased person for iBATIS, I must also be fair.
If I understand your post correctly, iBATIS is no different and has all of the same shortcomings as you've listed above.
Could you expand on how you find iBATIS to be better in this regard?
You say: "there are many bad designed databases in which tables do NOT represent an "object" in OO design". You are correct that an ORM tool will not work well with a poorly designed database but in any case it is best to avoid bad design. Since databse is the foundation for most business applications, you should focus effort on that area to avoid bad design and correct problems if you come accross them.
I think it's worth stating the obvious: there are plenty of *well* designed databases "in which tables do NOT represent an "object" in OO design."
Relational & OO are two very different models. If they weren't, this would all be easy, and hibernate, ibatis & probably even JDBC wouldn't be needed.
I agree with you that the "database is the foundation for most business applications", and in those circumstances the tool work to fit the database, not the other way around. Fitting to the database is the place where sqlMap absolutely leads the field.
>> Since databse is the foundation for most business applications, you should focus effort on
>> that area to avoid bad design and correct problems if you come accross them.
That's easy to say for simple, small, isolated applications. However, when dealing with enterprise applications that involve databases that you are NOT in control of, this is a difficult proposition. Certainly you will not get far if you call up SAP or JDEdwards to tell them that their DB design is bad becasue it won't map with Hibernate.
It is MORE common in my experience that the database design is beyond my control. In enterprise computing, there are MANY more existing databases that might be proprietary, legacy, controlled by a different department or are used by other applications that demand a different design (i.e. not uber-OO).
In enterprise computing, good OO data models are the exception, not the rule.
If you use Hibernate and like it. Great! I'm really happy that is it working for you. If you have used it and find that it has several features that are problematic then don't use it and consider IBatis. There is not an all encompassing perfect technology that is going to fit everyones preference. IBatis has features that are undesireable to people and I'm not going to try to force people to use it. If you want it? It is here for your consumption and participation. If you don't like it, there is a smorgasbord of solutions that you can try until you are bankrupt.
Personally, I prefer the clarity and simplicity of IBatis to fit demanding OO solutions as well as procedural structures. In an enterprise environment there is an ever continuing procession of design decisions that don't always fit into the perfect OO world and yet they are not "bad" design. Being that the database is often the centerpoint of your application, the decision is sometimes a compromise between what is OO appropriate and what is just plain best for copious amounts of data or complex relationships. So, IMO IBatis comes with the flexibility of meeting those demands at the price of verbosity.
I have found that these debates go on and on and on and on. I would encourage the IBatis user community not to make inflaming remarks about Hibernate. Although, I am not a fan of Hibernate and would not use it, I respect the Hibernate group and their efforts. They have the best ORM solution (IBatis is NOT ORM) around and they have given of their personal and professional time to accomplish this.
If we are going to discuss these things then lets do it in the spirit of improvement.
The offer was put out to write a Hibernate impl against the Pet Store model without alteration to the spec. I would say "do it or drop it". If you don't have the time, then perhaps someone else in the Hibernate community does.
Peace, Love and Granola,
I'd like to point out something that may be overlooked:
Very, very few of us are using truly object oriented databases - we are using relational databases, so please consider my comments in that light.
One hallmark of "rookie" database designers is that once they understand the concept of a trigger, they begin to implement business logic in triggers because it "just happens automatically". Initially, it is seen as both foolproof and very simple. The relationship of a trigger to a table row in my mind is very similar to the relationship between an object and a behavior in the OO world.
However, it soon becomes apparent in any system of moderate complexity that using triggers not only obscures business logic, but also can result in unforeseen and unfortunate side effects on performance, "circular updates" (anybody dealt with Oracle's "table is morphing" error?), etc.
My point is this: database transactions are not/should not be event-(or "behavior")driven, they are explicit and procedural. First do this, then do this, then do this, and if it all works, commit. That's why I believe if at all possible, business logic should be handled by the database (performance, suitability of language to task, and accessibility by widest variety of clients). If not possible, then it should be handled in a middle tier using procedural code, not "object-oriented" code.
The reason I prefer iBatis over ORM tools is because iBatis simplifies jdbc, but does not impose object-oriented behaviors. That sounds simple, but I think it's a big, big deal. There are good reasons why object oriented databases haven't caught on over the last 10 years - so why do we think that object-oriented database access is somehow better than relational/procedural? Are we just being java snobs?
What you are saying is very true. For cross platform compatibility, triggers need to be avoided. I have worked extensively with Oracle, DB2, SQL Server and what works in one may not work well in another. Good system design provdes documentation on business logic and as we all know is often inadequate. Those are reasons not to use the proper tool for the job. Just like a poor database design may preven the use of an ORM tool.
Talking in generalities, it is better to put the work in up front and design a good database. It also makes sense to document business logic so that anyone can follow it. Given those constraints I would consider triggers, ORM, iBatis, etc. as they best fit the task at hand. Often existing design, documentation, database implemention, performance constraints, etc. reduce the set of viable choices. iBatis is very flexible in this regard because it works well with triggers, stored procedures, and mangled databases. However, in a well thought out and planned development effort, ORM tools like Hibernate can work very well and provide high performance systems that can be developed efficiently -- it is not the right choice in the cases you cite.
OO is not reserved for snobs, but many have difficulty with the concepts and consequently fall back to procedural techniques. That can get you by but can reduce the chances that reuse will help you build better and more effective components.
Again i think you are making an unfair and uqualified statement. "design a good database" - A well designed database is not synonymous with Hibernate compatible. A well designed database is one that does not violate the business process and fulfills it's requirements in the most appropriate manner. I believe that the clear fact that a databaes is relational and java is intended to be OO requires our best effort to bridge that gap while allowing each nature to function as efficiently as possible. At times we may find that relying on the database's procedural functionality is much preferrable to maintaining it outside in a java layer. At other times, and probably most often, we may prefer java. I do believe in maintaining a good bridge between the database and the OO app. But, it cannot be a one way option. I believe that the Java layer must be able to conceed to the relational at times and the relational to the OO. IMO IBatis does an excellent job at providing that functionality.
I would appreciate it if you would stop making the assertion that a well designed database is synonymous with Hibernate compatibility. It's just plain silly and it seems to add creedence to the idea that OO purists are snobs. I trust, by your word, that you are not.
Also, I wish you guys with the name 'nobody' would kindly identify yourselves.
Are we done with this thread yet? I hope so.