Re: JPA and desktop apps

I'd like to add my 2p worth (2c for those using $).
The company I work for (cisx.com) wrote an entire suit of desktop
applications using Swing, JDBC and PostgreSQL.
We embarked on this project back in 2001 and looked at using more modern
architecture however with the likes of EJB2 on offer at that time we decided
that it wasn't mature enough and chose the above "old-school" two-tier
approach.
We wrote everything from scratch. An entire object based library that models
a flat table view of a SQL database. That is we modelled columns, rows and
tables. We created an API into the database via SQL VIEWS, so that the
client never has to perform joins, everything on the client remains as a
simple flat table. All of the business logic is embedded on the database,
however to make the client more user friendly you do have to replicate some
of this logic in the client code.
It works well as long as everything fits into the SQL table model. In the
real world this is not always the case and it becomes hard work trying to
fit "round pegs into square wholes" (the usual complaints).
We chose PostgreSQL purely on its LISTEN/NOTIFY capabilities such that we
have implemented an event driven model so that table views update
automatically (we modified the JDBC driver to get non-polling asynchronous
events from the server).

General complaints:
- Maintenance is hard work when you have 100+ tables.
- The system requires a lot of naming conventions to be followed.
- Swing is badly written and I would avoid it at all costs if we were to
start again. We had to modify JTable to get virtual views however the model
still requires in advance the number of rows in the table. COUNT is an
expensive operation on tables that have millions of records in them.
The number of "hoop jumping" and "hacking" you have to do to get everything
working nicely with the AWT event queue is ridiculous.
I could go on an on about the problems with Swing. The main thing to note is
that you don't have to be using JPA to be having problems with it.
- Remote client connections via firewalls / proxy servers is problematic.
Again we modified the JDBC driver so that we could use tunnelling
techniques. This required us to redirect port 443 on our incoming firewalls
to port 5432 on the database server, meaning we cannot host a secure
web-server on the same IP address. That aside, all works reasonably well,
however a lot of clients use "single sign on" for connecting to their proxy
servers and our application is non-compliant here because the amount of work
to modify the JDBC driver for this is beyond our available resources and
knowledge base. End result: a lot of clients have to have special proxy
settings just for our application, which they complain about endlessly...
- Upgrading remote clients means re-installing software on their computers
which is again not nice for these clients.
- Finally, there are many other areas that I have not mentioned, which
provide us with headaches - I'm only mentioning the main points here as I
have already rambled on beyond 2p worth...

Positive notes:
- High availability is simple with a two-tier approach, especially with
PostgreSQL's WAL system.

We are currently embarking on moving to a three-tier system using the thin
client model (web-server). The two technologies that we are considering are
GWT and Wicket.

There are so many things that the three-tier model architecture solves and
we believe these technologies are mature now. I would reconsider the
two-tier approach because no matter which way you go, JDBC or JPA, you are
going to have many problems to solve. IMO JPA is not designed for the
two-tier approach and you have pointed out many problems already and you
have only just started with the idea.
I guess you have to evaluate how complex the system you are building is and
whether it is worthy of a two-tier or three-tier architecture.

What ever you choose good luck!
Regards
Donald Fraser

----- Original Message -----
Subject: Re: [JDBC] JPA and desktop apps

> On 23/07/10 20:48, Lew wrote:
>> I don't find JPA a problem at all - it's a huge boost. Naturally you
>> have to deal with properly setting it up, just like anything else.
>>
>> If lazy fetching is bad for you, use eager fetching. Simple.
>
> Over potentially limited bandwidth connections where you want queries to
> run in a reasonable amount of time? You're kidding, right? Not everyone
> is using their app on the local gigabit LAN and doesn't have to consider
> the possibility of the user's wifi/cellular connection dropping out.
>
> There's a *huge* difference in bandwidth terms between "fetch customer
> id and name" and "fetch all the data in the Customer relation, including
> all its child objects like addresses and contact records."
>
> Sure, some things make sense to eagerly fetch, because you expect
> they'll get used in most parts of the app. But do you want all their
> addressing and contact details every time you fetch them? Even if these
> are (as in my case) separate relations accessed by reference, lazy
> fetching is still an issue.
>
> JPA offers few if any facilities to hook into lazy fetching to permit
>
>> You need to run DB work on a non-GUI thread if you don't use an ORM.
>> How is that different?
>
> It's not. My point isn't that JPA is particularly bad, just that I see
> very little advantage for its use in desktop apps in the *real* world.
> I'm frustrated by all the currently-fashionable-framework based examples
> that show it to be so "easy" and paper over the fact that actually,
> making it useful requires a completely different approach.
>
>>> Anyway, since folks here advised me to go for an ORM like Hibernate, I'm
>>> curious: How do you handle the need to avoid blocking on database access
>>> in your Java GUI apps, while lazily fetching properties of entities to
>>> avoid downloading half the database whenever you query it for anything?
>>
>> Proper design of entities to fit with a proper object model.
>
> Like, say, mapping entities from the database into native Java objects
> managed by an ORM?
>
> Isn't that the point?
>
>> Proper separation of view from model, just like if you don't use an ORM.
>
> Sure, that sounds nice. Now, we have this nice pre-made model/view
> system in Swing, where all the Swing controls have suitable model
> interfaces and are well suited to plugging in your own models.
>
> Let's just use JPA with that existing infrastructure rather than rolling
> our own new one. Most of them provide useful mechanisms to drive them
> with POJOs, lists of POJOs etc via simple adapters, so they seem an
> ideal fit for use with an ORM. Oh, wait, the Swing models aren't
> callback/event driven, so you can't lazily load without blocking the UI.
> We have to abstract the Swing models, building a model to drive the
> model to drive the view.
>
> This is what I'm talking about. Of course you can do it, it just sucks
> in terms of productivity. JPA, Hibernate etc can be used on the desktop
> in client apps, they're just (IMO) highly overrated. Most people who try
> to use them only seem to discover how many problems they leave to the
> programmer rather late in the process.
>
> Consider:
>
> http://blog.schauderhaft.de/2008/09/28/hibernate-sessions-in-two-tier-rich-client-applications/
>
>> Methinks you blame the hammer for the carpenter.
>
> Perhaps. Rather, I think this new JPA hammer is just a different kind of
> hammer, better for some problems and worse for others. It is rather
> overrated as the magic solution to all your database access problems as
> it's often touted to be.
>
> In this case, I think it hides and obscures more problems than it
> solves. I didn't know that when I started, and want to help others be
> more aware of the booby traps in this particular app design, caused
> partly by conflicts between JPA blocking-call lazy loading and Swing's
> non-blocking event-driven approach to GUIs. It's not that you can't make
> it work, it's just way, way more fuss and boilerplate than you'd hope or
> expect.
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>