I have a rather enormous project in which I’m trying to retrofit in-memory data. Essentially, I have a big collection of objects which contain primitives and other objects which exist in hibernate. Large sections of non-dao code rely on lazy-loading through hibernate to hydrate objects on the fly. However, since everything exists in memory, my object are not loaded, and I get hibernate lazy loading exceptions.
I could just manually implement hibernate lazy loading by dipping to hibernate and hydrating the hibernate object manually, but the object graph for that object is huge, containing hundreds of types that would need to be initialized and set. This seems impractical, and I’m looking for a viable solution to this problem. If anyone has ANY kind of tips, hints, solutions, or stories relating to this kind of problem or similar problems, I would be very grateful.
Thanks much.
If you are handling the sessions by hand, try passing object ids (row ids in the database) instead of full objects. Then preform a database read when you want to get the full blown ORM object and only keep the ORM object in a limited scope so it could be garbage collected when you were done with it. This would probably save you some memory.
This has a side effect of also limiting the amount of time you need an open session for. As you could open sessions (I would recommend a session factory) and close them as needed. However, I think there may be a significant database hit for opening and closing sessions (I think the underlying transaction is the real problem). You may want to look into JPA, which as far as I understand, doesn’t need a transaction for reads. Spring also has some nice features to automate transaction and session management they may want to investigate.