Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Nicolas Zozol
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 !) ?
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic