I can’t just copy and paste our code on the web. However, the idea of using remote lazy loading has also been explored by other people. There’s a fine article on TheServerSide that pretty much does exactly the same as what we have in place (apparently the source code snippets there are clipped, so be sure to check out the HTML source). Having lazily loaded entities is a bit harder than lazily loaded collections, so I’d advise to start off with the latter, which is actually pretty easy to implement. For lazily loaded entities you should really look at the Hibernate source code itself (start with https://github.com/hibernate/hibernate-core/blob/master/hibernate-core/src/main/java/org/hibernate/proxy/pojo/BasicLazyInitializer.java) to grok how it’s done and what parts you need to substitute. Poking around with a debugger in Hibernate’s source code is quite instructive to get a clear picture of what’s actually going on.

Then it’s simply a matter of replacing the bits in your Hibernate Configuration object:

EntitityTuplizerFactory f = new Configuration().configure(“some.cfg.xml”).getEntityTuplizerFactory();
f.registerDefaultTuplizerClass(EntityMode.POJO, RemoteLazyEntityTuplizer.class);

Where RemoteLazyEntityTuplizer is a PojoEntityTuplizer specialization that returns a special ProxyFactory returning JavaAssist proxies (implementing MethodHandler and Hibernate’s own LazyInitializer) that know how to get to your EJB facade when they need to be initialized.

I believe I will create a DB Persistence Service Module which will be responsible for downloading data objects and writing them back to the database. This should handle lazy-loading as well. Ideally, this will have a server-side counterpart and the communication between them will be HTTP-only in order to avoid cutting through firewalls. This should be able to handle HTTP proxies.

Hibernate should not be visible, only JPA style annotations should be used on the data objects.

If someone knows about such persistence service (using JPA, with server and client side, communication is with HTTP) please, let me know (soltesz(point}andras (at) gmail dotcom)..

I am also rewriting my rich client application to work with completely detached objects and hacking lazy loading back into the game (not using Hibernate’s default lazy loading).

By the way: A Hibernate session dying on you while saving a new/modified object back to the database is the ugliest thing you can imagine. It is extremely hard to shake the session back to shape in order to continue using it. We do the following when saving:
- We merge every dirty object into a session created specifically for the save operation (save session)
- We save the objects, this may succeed or fail
- We drop the “save session” and merge objects back to the original session
- If an object was meant to be saved but the save operation failed, we clear the ID field which was filled out during the save operation

This way the “save session” will always be dropped after the save attempt and cannot cause further problems after it failed once.
The original, “query session” will remain intact, even if the save operation failed.

The trick is to write your own EntityTuplizer (and register it with your Configuration object) that returns an implementation of the HibernateProxy interface (or implementations of the PersistentXYZ collection interfaces). When Hibernate creates a lazy reference it will always store the name of the association and a serializable PK blob. That can then be used to fetch the relation “JIT” in a new Session. For the collection interfaces you can get away with plain Java but for the case where the destination of a relation is a POJO you’ll need to use a bytecode generation library like Javassist (like Hibernate uses already).

Say you have a one-to-many relationship. You query the one-side with some constraints and you display the resultant entities in a JList. When the user clicks on an item, the “many”-relationship (usually a Set, but can be a POJO as well) is traversed. Under the covers, the PersistentXYZ collection will go through a special facade with the PK and association name to fetch the association just-in-time. The downside to this is that you can block the EDT with DB-access unknowingly. Usually the access is <250ms, so quite acceptable. If it's really becoming a problem after profiling we wrap the access in a SwingWorker and show a fancy "please wait" animation.

Of course, at some level you still have to be cognizant that the objects you're dealing with are eventually fetched from a database. That's why we have methods on our SessionBeans that deliver a fairly "wide" object-graph for the client to begin with. The rest is fetched lazily (our Swing clients go through our app-server, but as noted before, the clients can use Hibernate directly).

We work exclusively with detached entities and merge them back in again when a user saves something in a form. This has the "downside" of needing a good equals() and hashCode() implementation but that will pay itself back big time down the line (although I had to fight many battles at work to make people not write hashCode() implementations that NPEd all the time). If you prime the L1 cache with a good query the merge will only have to perform insert/update/deletes. Fetching and persisting your entities is still not completely transparent (methods to select/save a graph of objects on your facades) but still a whole lot better than the procedural nightmare of EJB2 with DTOs everywhere and different methods on your SessionBeans to traverse associations.

Yet ‘enforcing’ this kind of constraint in the gui, without using the locking catches many cases of constraint violation, which would otherwise only get caught by the database, rendering the session unusable.

There is only a small gap left, for another user entering the same value at almost the same time and the database constraint takes care of that.

The performance cost of this approach is very limited, since we only use a select on an indexed column and no locking.

So for us it was a nice compromise between performance, ease of implementation and usability.

I wanted to say that validating some type of constraints is not possible even conceptually in the application layer without locking tables that are involved in such validation. Consider unique key validation. The only way that guaranties uniqueness and would not throw a unique constraint violation is to do the following sequence of actions. 1. Lock the table from modifications 2. Query this table for duplicates of an incoming data. 3. If no duplicates found, insert incoming data. 4. Unlock the table or commit transaction. This is workable, but in my opinion cannot be a solution for concurrent multi-user enterprise level application.

Any other algorithm may render the assumptions of querying for duplicates invalid at the time of the insert.