Hi Steve, > Take 'temporaryIdTableDDL' as the perfect example. Hibernate cannot know at > start up (building the SessionFactory) that the application will or will not > use HQL updates/deletes against "multi-table structures" that would therefore > need access to 'temporaryIdTableDDL'? > > And the problem with lazily generating them later is that that would require > keeping around the Configuration as part of the SessionFactory.
If we optimize memory consumption of Configuration, I doubt it would be a big problem to keep Configuration in memory. > > Hm, I had not thought of the UserType ServiceLoader approach. Thats > interesting, though not at all related to the "instance per usage" situation. > > If you want to get around having an instance-per-usage, use the TypeRegistry: > http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#types-registry Is it possible to use TypeRegistry it in JEE environment? I mean, the container creates the Configuration and SessionFactory. Is it possible to hook up into this process and add my own UserTypes? Configuration could use ServiceLoader to find all application specific UserTypes and register them in the TypeRegistry. > > Configuration is not kept around by Hibernate itself once the SessionFactory > is built. Nor is SimpleValue. And as Hardy already mentioned, that code is > undergoing major changes already for 5.0. As Sanne already mentioned Configuration is not garbaged collected in Hibernate 4. In memory dumps I see three objects, which are still references Configuration once the SessionFactory is built: - direct reference SessionFactoryServiceRegistryImpl - indirect reference from inner class created in Configuration#buildSessionFactory() (lines 1770-1781) - indirect reference from inner class created in constructor of SessionFactoryImpl (lines 230-253) Best regards Andrej Golovnin _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
