Rickard, > One of the issues were with how version numbers are handled with many-many > associations. I don't recall all the details right now, but essentially if > you changed an association on one side, it effected the other side to the > point where you would get a lot of (seemingly) unnecessary failed > transactions under high load because of versioning issues. Also, Hibernate > didn't seem to handle complex value objects well, which is a problem. In > general many developers seem to favor making everything entities, because > Hibernate prefers it that way.
My guess we are talking of Hibernate's optmistic locking failures due to the fact that if an entity that belongs to a collection in some other entity changes its version the owning entity version changes as well - and I can see how tihs might lead to "(seemingly) unnecessary failed transactions under high load". IMHO this is a misuse of optimistic locking (not even misuse of Hiberante). If one has a high load and great degree of interference between the entities one should use pessimistic locking or retry transaction if it is not too expensive. But as I mentioned this is MHO. Complex types, yes, they are a bitch but totally avoidable as you mentioned. > There were other stories about problems with the cache system, that were > severe enough to question whether it is useful at all. Absolutely agree, caching system is weak and at times absolutely useless. But in Qi4j does it really matter? Probably not so much. I think a bigger problem, as Robert has mentioned in another email, is how does one map complex scenarios onto RDBMS. Up until I watched the oredev videos I had no clue that things could get very complex and naively believed that mapping onto RDBMS should not be a big deal. Now me thinks differently :-(. Still it is worth a try. It will be complicated though, hence I think we should try to minimize the effort on the low level mapping details (types and all that shit) and concentrate on how we do the really complex things. Alex. _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
