What is the BEST way to pull data out of the hibernate layer and into another tier?

Question

As my previous posts can attest, I'm retrofitting in-memory, network-cached performance to what was once an entirely hibernated scenario. In doing this, I'm hitting problems where I deal with proxied objects and need to reattach to sessions, but in doing this I also want to maintain transactability. What are the best practices from moving complex logic out of the hibernate layer? I'm just now "fully" coming into hibernate, so this is a rather hateful experience.

Can anyone who has worked with this kind of data movement elaborate on how you overcame the transaction problem, dealing with proxied objects, etc.? I'm just looking for general resources right now, as I'm struggling to swim.

Thanks.

Answer 1

I think you are referring to the practice of "Modifying detached objects"? Typically this is accomplished using the session.merge() API.

see: http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#objectstate-detached

HTH

Answer 2

You need to decide on 2 things:

• Your session management strategy
• Your associated fetching strategy

There is good post by Gavin King that explains some of the options for handling sessions (the post is about performance, but is generally applicable too).

As for fetching, one thing to consider is increasing the number of primitives made available by your Hibernate layer. E.g. imagine you have a entity Foo that has a 1-N relationship to Bar and some circumstances you need just the Foo objects, but in others you need both the Foos and the child Bar objects. You could those represented as separate calls to the Hibernate layer.

class HibernateLayer {
    public List<Foo> findFoo(String someCriteria) {
        Query q = new Query("from Foo f where f.someCriteria = :1");
        //...
    }

    public List<Foo> findFooWithBars(String someCriteria) {
        Query q = new Query("from Foo f left join fetch Bar b where f.someCriteria = :1");
        //...
    }

This has 2 benefits, 1 you won't deal with lazy loaded proxy objects, you'll have all the data that you need and it will perform better as the SQL generated will be more appropriate to the situation. However it will have the drawback that you will need to know before calling the Hibernate layer whether or not you will need the deeper level of data. To ensure that your data remains consistent (the main purpose of transactions) make sure you use optimistic locking at the very least.