Question more than issue: Does Entity Pruner handle case of serialization w/o hibernate classes

[mikemil]

Hi,

This is more of a question. I found the blog post from years ago about this problem and think we are encountering something similar and wondering if the entity pruner would be a good fit.

We are migrating from Hibernate2 to Hibernate3. All servers can NOT be upgraded at once. Store servers are sending objects to a Central repo and saved in the database. Central is upgraded first and at H3, but stores are still at H3. We serialize the objects and put them on a JMS queue to our Central, which de-serializes the objects and saves to Central DB. Now we are getting class loader problems because the net.sf.hibernate.* jars are not on the H3 server. We always use lazyloading=false because or clients are Web Start Swing clients so lazy is not an option.

Seems like we shouldn't be doing this with the Hibernate objects in the serialization so wondering if this tool is a good fit or if there is something that fits better?

[stevesaliman]

My first thought is that it would be a good fit. When I first wrote the Entity Pruner, I was thinking about XML marshallers that were running into problems trying to use reflection to convert objects to XML. I wasn't really thinking about removing references to Hibernate itself, as a side effect it does exactly that. As long as the pruning is done on the H3 server, and not the H2 client, you should be OK.

It's a shame you have to set lazyloading=false. I once worked at a place where we needed to send objects to a client. We kept getting Lazy Load exceptions so we turned off lazy loading (this was before the Entity Pruner). The screen needed 8 records from the database to display a summary screen when the user first logged in, but the application was loading - and I'm not making this up - 23 million rows of data and streaming it to the client. It took about 20 minutes for the first screen to display properly. When we trained users, we told them to login at the start of the day and whatever happens, don't log off :-)

If your data model is small (not many objects, not many rows), you will probably be fine, but it can get out of hand pretty quickly.

For now, Id columns need to be a Long. I'm working on a new version that can have any Serializable object as an ID (Long, Integer, String, etc.).

Steve