There has been much discussion on various threads about the problems encountered when lazily loading object relationships across a network. Basically, it seems that as soon as the proxy is serialised and transmitted to a remote tier, it loses its connection to the session and cannot initialise itself when required.

It appears to me that this imposes a great restriction on lazy loading. Its a great feature that allows you the freedom to develop a complex object model, without a large tree of objects being loaded for every data record. But unfortunately, it can only be leveraged by code running in the same JVM.

I can see that the proxy classes (eg. CGLIBLazyInitializer) have a reference to a SessionImplementor that loads its state when required. Would it be possible, or for that matter, desirable, to have object and collection proxies refer to a Remote handler instead, that could call the session in another tier to load its state as needed?

Note that I am not implying non-transactional loading, as this proposed proxy functionality would only work within an open session, much like the 'Open Session in View' pattern.

I can see that someone else has done something similar (http://article.gmane.org/gmane.comp.jav ... evel/1433/), except it appears they use these proxies for every object that's loaded.

Scott

Remember that your primary option is to fetch all required data (the subgraph you need) before you pass back to the client tier! Hibernate has very flexible fetching, with HQL and Criteria. Lazy loading is the second option and I'm not convinced that it makes sense across tiers. We've been thinking about that several times, and any "automatic" lazy loading with a new Session would break transactions (Detached Objects pattern requires version checking).

Your approach, with a single Long Session (disconnect/reconnect pattern) per application transaction, may be valid, but I really fear that users don't understand it and use it instead of fetching. Why not implement a patch and discuss the implications of that on the developer list?

Session.lock()

Absolutely not. I am an immediate veto to anything like this.

I think it must be trivial to implement "outside" hibernate, implement wrapper for session as statefull bean and return custom proxies from "remote session",
you can use custom proxy for "remote session" on client too for more fun.

The advantage I had seen with lazy loading across the tiers was that a GUI could allow users to "turn off" unwanted data for viewing in preferences. The client layer could leverage lazy loading to only retrieve data that was required.

I guess one alternative is to have the client specify what data to fetch. Another is to have the service layer return the maximum sub-graph likely to be needed. I will probably go with one of these latter options.

I had a look at CarrierWave. While I liked the ability to specify a fetch depth and 'fuzzy' ends (ie. ends that are remote references), I didn't like the code-generation approach, and I found the whole architecture overkill for what I was looking to achieve.

On a side note, I think a useful api would be something similar to CarrierWave (or Service Data Objects), with the ability to specify (in configuration or in API), at a fine level which properties should be copied by value, and which should be made remote calls. The proxy object transmitted to the client side would need to record any changes made to the copy-by-value data (ie. by the client), and transmit all these changes prior to any calls to the remote method calls, to synchronise its state with the remote POJO. The advantages would be that rich domain models could be modeled and transmitted to the client without the client needing all the support classes on the classpath, and the network traffic could (hopefully) be reasonably efficient. But then again, this all could be an unnecessarily complicated alternative to a well-designed service layer.




Just curious, but what are the objections to this?

Scott

Hi all,

I am also perplexed by the hibernate team resistance to extending lazy loading across tiers.

Several J2EE implementations AND JDO implementations already support this.

So why not Hibernate?

TIA,

--steve p.

here in america, mothers have a favorite saying: "If your friends jumped off a bridge, would you too?". Meaning, just because others do it does not necessarily make it right.

The issue has to do with transactions. The problem is that a lot of programmers (for whatever reason) tend to only think of write consistency when they hear the term transactions. But there is another side to that coin, namely read consistency or transaction isolation.

In order to facilitate lazy loading across tiers, you would also have to facilitate lazy loading outside of transactions. That is more the concern.

This is a definite misfeature, as has been discussed many times. Fetching data piecemeal across the network does not scale, and breaks transaction isolation.

I have seen Gavin and others write that data reading should always be done within a transaction. And I know that JDO enforces this (all operations occur within a transaction), whereas Hibernate doesn't (it is possible to do reads or writes outside a transaction).

My question then is, if you are not updating the data until later, do you gain anything by reading within a transaction?




Not if you are only reading it first (and maybe upating it later). And besides, transaction isolation issues will still arise across tiers, since (typically) a client wants to read the data, modify it, then transmit the changes back to the server. Ideally all three processes would occur within a single transaction, but this opens up the risk that the client might die and leave the transaction hanging. So in any event, you are still limited to reading and writing in separate transactions anyway.

Scott

There is no database access outside of a transaction, ever.

Oh, and you have to update yourself on "application transactions", optmistic concurrency and automatic version checking.

Ok, I didn't realise that. Do you mean that a call to Session.list() starts a transaction if one is not already begun, or that an exception will be thrown if no transaction is current?



I have read the docs on this, but I am still unsure how Hibernate does version checking if you don't specify a version number or timestamp column. Do you just check against all original loaded values within the update statement?

Scott

I have just seen in the docs for <class> where it says that you can only do optimistic locking on column values (as opposed to versioning) when dynamic-update = true. And I see in the source code that you can't do optimistic locking on column values with joined-subclass mappings either. So I guess that answers my question.

Scott

This is not Hibernate specific, but you simply can't communicate with a database outside of a database/system transaction.