Questions about Architecture with Swing and Hibernate in a client/server application

Nicolas Zozol

Ranch Hand

Posts: 33

posted 6 years ago

Hi,
I'm working since last week in a much older application, and it seems to me that something is wrong.

It's a Swing application making database acces in a long distance server, sometimes with Hibernate, sometimes directly with JDBC, because they say that hibernate is not efficient enough with complex queries.

I didn't have time to llok deeper in the application, but it seems that each swing client opens its own Hibernate session, on its own JVM.
But I suppose that, in order to keep cache abilities, Hibernate should be on the server side, and we should use RMI (or http+serialization) between client and server. As done currently, two users don't share the same cache. And Hibernate & jdbc might be not synchronized - I'm suspecting that cache is in fact disabled.

Is my reasonning correct ? Is it well an anti-pattern ? Does Hibernate suffer from complex queries (I don't believe it one second !) ?

Why don't you believe it? Consider the overhead in making large, deep conversions between a result set and the associated domain objects. Consider the potential impact of a potentially untuned SQL statement for complicated queries, particularly if the DB isn't set up to query efficiently in the way Hibernate is querying? Fortunately, it's easy to test, because you can take Hibernate's queries and run them manually and check for specific performance impacts yourself.

Caching isn't necessarily to cache *every* request made, but a particular user's requests. Which is more useful depends entirely on the application and its use patterns. It's *possible* your application would be best implemented with SOA, but I don't know that it's possible to make any generalizations without knowing more.

Nicolas Zozol

Ranch Hand

Posts: 33

posted 6 years ago

Hi,
What I meant is that I doubt that Hibernate will always suffers dramatically compair to jdbc for complex queries, and that my society must do these jdbc queries.
I think that Hibernate should be on an application server, not directly used by the swing client, and I wanted a kind of confirmation - or not

It'll always be slower than plain JDBC and tuned queries/DB. Even if the Hibernate query and DB are tuned, it'll still be slower. Dramatically? Not for simple queries. For deep queries with multiple joins (hence substantial object creation), it can be pretty substantial. Plus naive queries can create many DB round-trips, which *is* dramatic (n+1 query issues, see here for a brief explanation).

There's no "should" when deciding where Hibernate should live--it depends on the application, data, and infrastructure. SOA (despite it having been a buzzword) does have a lot of advantages, server-side caching *potentially* (but not necessarily) being one of them.