Hi,

I'm experimenting again with porting our ORM framework over to hibernate, but seem to have the luck finding the weaknesses of hibernate all the time...

This time, as I've given up upon my "mixed mode mapping", I took one slightly larger project (400 classes) over to hibernate and ran into memory probs.
First of all, switching off batching helped a little bit in getting the memory consumption from 145 MB (!) down to some 50 MB. Still much too huge (Castor needs only 20 MB), so I decided to delve into the source together with my profilers help and voilà it's the saved queries. After patching AbstractEntityPersister to create its queries at runtime I could shed it down to some 25 MB (that it, still some 10 MB static query strings).
Now, after some performance tests I decided that it would be better to try table per concrete class inheritance mapping. So I created the necessary converter classes for my data and failed due to instantly crashing my JVM during creation of the SessionFactory. Analyzing this further showed me, that the queries generated by this kind of mapping are, ehem, *huge*. 1.6 MB for one query. Multiply this by about a few thousand (ok, not *all* queries are that big, but the more polymorphic, the bigger), and you see, why.
Question now is, is there any possibility except stored procedures or views to get around this problem (=runtime generation of the queries, completely omitting this rubbish, shortening the aliases, things like that), or is the only advise available to work with views?

Thanks in advance!

Patric

That's interesting - I've got ~3000 mapped classes (using table per concrete class) and it doesn't seem to be anywhere near that bad, in fact most of the memory seemed to be consumed by all of the generated proxies last time I looked.

I'd guess that in your case most of the bloat is to do with the implicit polymorphism? If so, do you need this? If not then does setting polymorphism="explicit" in your mapping file help?

You may also be able to reduce the amount of static SQL by setting dynamic-insert and dynamic-update in your mappings, although I guess your patches to the AbstractEntityPersister will already have had the same (and more) effect.

On the positive side of things at least the prepared statements should mean that the DB shouldn't be re-parsing your SQL all the time.

I already thought upon that, but it's absolutely impossible for me to use explicit polymorphism, it would completely destroy the compatibility to the ORM we used before. For me, it's a very important design pattern having polymorphism in relations and queries; honestly it's one of the reasons for me to use ORMs at all.
The dynamic-insert and dynamic-update is set already, otherwise it would be much worse, the patch does something like dynamic-select-for-update or such, which further decreases footprint.
What would be nice, is, that somehow the select queries would always been built when they are needed and held in a soft reference cache, so that if the aren't used for a while, they could easily be collected by gc. That way, it could save another 10-12 MB footprint in my case (so only 400 classes in joined mapping), or even save hundrets in case of the union case.
For the meantime I've decided to use views; it should reduce these select queries somehow. Question is how to use that in detail, I will have to consult the documentation on how it can be done...

tia

Patric