A way to handle Hibernate's LazyLoading with remoting

Quote:

---

Originally Posted by jwray

I could be wrong but this almost sounds like it might lead to one of the initial problems that occured with people using entity beans in ejb. Too many remote calls for data access leading to awful performance, which in turn lead to the DTO pattern that basically advises locally populating an object with data before shipping across a wire.

---

Definitely true. That's why I said the performance would remain the biggest concern. Although I don't expect it to be as bad as entity beans. There are some techniques to relieve the pain - those references most frequently referenced can be 'touched' (thus pre-fetched) on the server side, the client can leverage its own cache, etc. I'm even thinking about using hibernate on the client side as well, backed by an in-memory hsqldb as the cache. This way perhaps even the DAO's can also be reused on both sides.

Yep, I think a large part of the problems with enitity beans came from using them while ignoring the fact that data fetching was happening remotely. You're obviously not doing that here though.

I'm using the Hibernate second level cache on the server side and I prepopulate it with certain objects at application startup. For example, object collections that end up populating a list in a dialog, and I keep meaning to expand this approach, it works well. I like your idea of a client side cache, I can see a couple of places it might well work in my application, I should look into it in more detail.

On a more general note, I've found remote client tuning ends up being a number of trade offs between memory, speed etc. On the other hand, in most places in my application I've found users are happy with a little delay as long as they are told what's going on via a progress indicator and something as simple as a Fetching ... message. So, a lot of the time I don't invest that much energy in finding the optimal trade off result, unless there's a glaring problem.

Quote:

---

Originally Posted by manifoldronin

Definitely true. That's why I said the performance would remain the biggest concern. Although I don't expect it to be as bad as entity beans. There are some techniques to relieve the pain - those references most frequently referenced can be 'touched' (thus pre-fetched) on the server side, the client can leverage its own cache, etc. I'm even thinking about using hibernate on the client side as well, backed by an in-memory hsqldb as the cache. This way perhaps even the DAO's can also be reused on both sides.

---

Quote:

---

Originally Posted by manifoldronin

Interesting topic. I am working on a project that will need to support both Web and rich clients.

---

The project I work on also has a web client. The good thing about the proposed solution is that it works in the context of a remote invocation and doesn’t affect local calls, so it will be friendly with patterns like “open session in view”.

Quote:

---

Originally Posted by manifoldronin

I'm even thinking about using hibernate on the client side as well, backed by an in-memory hsqldb as the cache.

---

Using hibernate in the client this way sounds new to me, wouldn’t you need a replicated clustered cache to do that? Does hsqldb do that?

Quote:

---

Originally Posted by fschroder

Using hibernate in the client this way sounds new to me, wouldn’t you need a replicated clustered cache to do that? Does hsqldb do that?

---

oh, no, no, that's not what I meant. :) It doesn't make sense to cluster caches on server and clients. I just want to use a client-side cache to speed up frequent getter access. There are clearly a couple of assumptions:

1. all the write operations would still need to go stright through to some server-side service interface, which would also be the transaction boundary.

2. the nature of the access to the objects being cached can afford a short period of possible out-of-sync data, say, 3 minutes. From my experience, navigation on a particular object instance tends to follow a burst pattern, i.e., access to this instance and its related ones becomes intense during a short period time. E.g., when a button is clicked, or when a screen control is populated. During this short period, the volatility of the data is usually not a serious issue (remember we are still talking about read operations).

And it can be any cache implementation, not having to be hibernate+hsqldb. I was thinking of them just so that the DAO's themselves can then probably be reused on both sides.

Quote:

---

Originally Posted by fschroder

Here’s one of them:

public class PersonRoleInitPlan implements InitializationPlan<AbstractPerson> {
public void init(AbstractPerson o) {
Hibernate.initialize(o.getRoles());
}
}

I could have initiliazed the roles collection by “iterating” it (to avoid coupling the domain with hibernate), for example:

public void init(AbstractPerson o) {
o.getRoles().size();
}


The anonymous approach seemed nice to me, but I’m using RMI, and using anonymous classes means it will also send the top level class through the network, something I’d like to avoid, so I ended with named initializers.

---

Hi,

I work on a 3-tiered app with Java clients and a Spring/Hibernate server acessed over RMI, so your approach is of great interest to me. However, I can't figure it out with so few code. Would you mind giving us a more detailed exemple, with a sample domain object and a bit of client code?

I'd be grateful for that. Regards,
Baptiste

I have also come accross a similar problem. My server has to have a very generic interface, since it has many clients (currently a webapp and a rich client), both of which can be extended by thirdparties through plugins. The requirements for these applications (in terms of the data they need) is not known to me, since it will depend on the client/plugin. So for example exposing a getUser() method that returns the User object and all associated related objects may make sense for the rich-client app but not for the webclient.

In the end what I decided to do was to expose a QueryManager service, which allowed the client to specifically get just what information it requires. In essense the QueryManager provides a number methods that take in a query and associated parameters and returns a List of the results. The QueryManager is
a bit smarter than I mention here, for example it can support multiple query
language flavors (currently HQL and SQL), provides names queries for often
used queries etc...

This design also meant I could get rid of all the methods I used to have in
my other service interfaces that were strictly related to data retrieval,
cutting down on the code drastically.

But for this to work you need to design your persistent objects with this in
mind. No lazy loading, for one. You also need to know who is executing the
queries if you have priviliged data and then use hibernate's filters to prevent
un authorised access to data. Since I was already using acegi, this was trivial.

Not using lazy loading may seem like a big compromise, but I have found it is
not since clients always load precisely what they need and nothing more.

There is something similar on the Hibernate forums: http://hibernate.org/377.html .

Quote:

---

Originally Posted by baptiste

Hi,

I work on a 3-tiered app with Java clients and a Spring/Hibernate server acessed over RMI, so your approach is of great interest to me. However, I can't figure it out with so few code. Would you mind giving us a more detailed exemple, with a sample domain object and a bit of client code?

I'd be grateful for that. Regards,
Baptiste

---

Sure, I have run out of time today, but I’ll post something tomorrow. :)
Federico.

Ok, here is the code and a little example.
Not precisely a polished document :rolleyes:, but it should get readable once you format de code. The JDK 1.5 parts should be easy to extract if you can’t use them.
Hope this helps figuring things out, and if it doesn’t don’t hesitate to ask.

Regards,
Federico.

Quote:

---

Originally Posted by fschroder

Ok, here is the code and a little example.
Not precisely a polished document :rolleyes:, but it should get readable once you format de code. The JDK 1.5 parts should be easy to extract if you can’t use them.
Hope this helps figuring things out, and if it doesn’t don’t hesitate to ask.

Regards,
Federico.

---

Thanks a lot. It's getting clearer but I still have difficulty getting the whole picture. I haven't worked with Java 1.5 and these kinds of aspects before, so this explains that.

Regards,
Baptiste