Hibernate version: 3.1.2
Spring 1.2 w/subclassed LocalSessionFactoryBean (to generate Entity Names from original XML mapping files)

I have an application with about 30 basic Hibernate entities. Maybe about 5 of these entities have 100 - 200 columns of Doubles in them. Due to being forced to work with a horrible, legacy database, all 30 of these entities have 30 types of tables which are duplicated 100 times in the database (for segmentation of the data, to cut down on row count). We're using hibernate's entity names feature to map each of the 100 tables of a kind, to the same java class. To recap so far, I have 30 classes, each of which is mapped 100 times to a different table using entity names, for a total of 3000 tables/entity names. About 500 of these entities contain 100-200 columns of Doubles.

When I start the application, as Hibernate's SessionFactory is being built, I eventually get an Out of Memory error. I've cranked my heap up to 512Megs so far and it's still not enough. I could keep cranking up heap, but I'm concerned that there's a fundamental inefficiency with our use of entity names or something. The obvious solution is to redo our schema to be efficient/correct but we're not allowed to touch it in any way just yet.

We thought a lot of memory was being eaten up because of the XML parsing Hibernate's doing on each of the 3000 mapping files that are being loaded into it. So we tried subclassing Hibernate's Configuration class to teach it to just load the 30 base XML mappings and one-at-a-time, grab the resulting PersistentClass for each, clone it using XStream to Serialize/Deserialize to new object, change the table and entity name on the clone, then add it back in by calling and calling on that. The thinking was that if we could just add the PersistentClass directly, we'd bypass the XML stuff (at least, within Hibernate, I know we're still using XStream's own XML stuff, but hoped it'd be more efficient), hoping it was the XML stuff in Hibernate that was killing memory the most.

Anyway, this approach hasn't worked either. Memory usage is still through the roof. Does this approach even begin to sound workable and if not, can anyone think of another way. Does our thought of what's eating all the memory even seem right? We tried profiling the app and saw a lot of memory being used within the SessionFactory creation but found it hard to fully pinpoint (someone else did that profiling).