We are developing a Swing-based application launched via WebStart and we would like to use Hibernate on the client side. I know this sort of architecture has been discussed here before, but I have somewhat different needs than those before me. We are going to use VJDBC (http://vjdbc.sourceforge.net/) on the client side to connect to our database (the JDBC driver basically acts as a proxy to a servlet which actually runs the queries for those not familiar). The client Hibernate session will be read-only. Any changes to entities must happen on the server! We are communicating with our server via Spring remoting (not that it really matters, but thought I'd throw it in). Anyway, we're currently looking at two different scenarios:

1. Create one session with a long-running transaction so that all relationship traversals work without having to monkey with creating new sessions all over the place. Since we're read-only, this shouldn't be a big deal.

2. Scrap using Hibernate on the client altogether and just return our entities pre-loaded with whatever they'll need on the client side from our remote services.

I would like to hear what the experts think about this. If I choose option 1, I think I'll have to do some real coding to get Hibernate to work like we want (i.e. to support a pseudo transaction which doesn't really keep track of changes and allow the first-level cache to be garbage collected to avoid memory leaks). Option 2 means we have to do a lot of pre-fetching and write a lot of versions of query methods (or come up with a fetch graph API), but it is simple; if we got a LazyInitializationException, we'd know exactly how to fix it (make sure that relationship is fetched before returning). Am I missing something? Which way would you do it if you were in my situation? Any advice would be greatly appreciated!

Thanks,

James

Hibernate version: 3.2.2.ga [/list]

Mr. Bauer,

Thank you for your reply. I am looking over your code to see if there's anything I can pull from it to use. However, I did neglect to mention one little stipulation about our project. We're dealing with an existing (and rather large) codebase, so we would like to minimize the impact as much as possible. Our existing ORM framework (a proprietary framework written in C++) allowed us to do one big session and we never ran into memory problems. I don't know if that means that it allowed garbage collection or if we just never had enough objects in the cache.

Is there any easy way to make hibernate behave in a read-only mode which also allows garbage collection (the references don't have to be maintained if nothing is changing on them)?[/quote]

No, you need to manually manage the persistence context cache of a Session with evict(o) and clear().

By the way, it would be trivial to implement automatic eviction with a mechanism such as the AutoReleasePool in Cocoa/Objective-C. Write your own implementation of an AutoReleasePool in Java, put all instances that are loaded into the Session in the appropriate pool on loading (use an org.hibernate.Interceptor), and release the pool once you are done with the instances. Manual memory management is not completely evil.