Skip site navigation (1) Skip section navigation (2)

Re: JPA and desktop apps

From: "Donald Fraser" <postgres(at)kiwi-fraser(dot)net>
To: "[JDBC]" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JPA and desktop apps
Date: 2010-07-27 15:00:19
Message-ID: 06E310975F5E4C4EB8F3DD6523A120DF@DEVELOP1 (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
> I'm using a lot of stored procs as well as using views and HQL joins, so
> I don't have the same square peg issues you've encountered. I sure do
> have the Swing issues, though...

We have 565 stored procedures and if the square peg issues were our only 
problems then we wouldn't be considering moving away from this architecture. 
The square peg issue is a minor inconvenience compared to the rest of the 

>> 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.
> Out of interest, why not JSF2?

There are so many flavours of enterprise architecture that claim to solve 
all your problems that you have to look at what you think are your most 
difficult problems and do they solve them.
As far as I can tell there are still a lot of naming conventions required 
for JSF2 and boiler plate code to map things.
I'm reading a lot of forums to see what issues people have and what they 
think of these technologies.
People that were once JSF2 ambassadors that have moved to Wicket claim it to 
be so much better, hence why its not in my short list. I might be wrong but 
you have to start somewhere and have some system of reducing your short list 
before one waists a lot of time in writing test apps to really find what the 
issues are. In short we are looking at key areas that we think are the 
problem areas and investigating these issues. Namingly we would like a pure 
message based system which requires ajax technology to make it work on the 
thin client. So we are focusing on the ajax problem areas to see whether 
these technologies cut it or not...

> I'm seriously considering dropping my own app completely in favour of a
> server-side rewrite, as I'm increasingly coming to see that while JPA
> makes some Swing issues worse, and it has some big problems in the
> desktop app context no matter what toolkit is used, a fair chunk of my
> problem is with Swing not JPA.
Here here!

> Note that I'm completely, 100% green on server-side Java, to the point
> where I'm still wondering if Java is the right choice - perhaps I should
> throw out my JPA/Hibernate mappings, validators, etc and re-plan the
> whole affair entirely. So perhaps it's obvious why JSF2 is a bad choice,
> and I'm just too green to know it.

We're pretty green on the server side Java too having spent the last 10 
years working entirely on our two-tier systems.
We do have server side code for automation, however this is pretty simple 
code that only uses the Java SE VM.
So we were pretty taken back when we loaded up GlassFish and started reading 
up on what it has to offer. We could spend the next 6 months just learning 
the in and outs of this JEE platform and is this the right JEE platform to 
use? Yet another decision to make.

> Perhaps I should've just written the whole thing in PHP :S
Yes, our web-server code is PHP and we recently reworked the entire site so 
that it is completely OO.
Its crossed my mind several times to say lets just write it all in PHP but I 
have faith that these new technologies will work for you if you use them how 
they were intended to be used. If only I had more time....

>> - 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...
> Interesting issue. Thanks for bringing it up. I never really considered
> over-paranoid outbound packet filters as a likely issue when using
> PgJDBC, but given my intended use case involves a lot of roaming users I
> can see it would've potentially become a support concern.

On top of the firewall/proxy server issues you have the session connection 
management problems.
We limit each individual user to only one connection and because we are 
using a normal TCP socket connection, most of the time, things work OK. 
However when a connection is dropped over the internet the server will keep 
the connection open until it knows otherwise. This causes problems when the 
user tries to re-establish a connection. Unless you have session management 
in place you don't know which connections need cleaning up... All of this 
code had to be written in C, as a plug-in to the PostgreSQL server.
If I was to do this part of our app again I wouldn't use JDBC directly. I 
would use a message bus to deliver the SQL requests / results sets. Your 
users then scale better. Most message buss implementations have the option 
to use the HTTP protocols as a delivery mechanism which makes tunnelling out 
of firewall/proxy servers easy. Single sign on - not a problem, Sun 
implemented this with the HTTP connection classes (If only the source code 
to this was available...)

> I'd be really interested in sharing experiences down the track on the
> web framework side of things, as it sounds like we have similar needs
> and I'm about to start writing a test app in each candidate framework
> (!!) to see which sucks the least for my purposes.

It does seem that we have a lot in common and have come to many of the same 
I too would be interested in sharing experiences. What pit-holes did we 
uncover etc...

I'll keep you posted on any significant findings.

In response to

pgsql-jdbc by date

Next:From: dmpDate: 2010-07-27 16:44:51
Subject: Re: help
Previous:From: Kevin GrittnerDate: 2010-07-27 14:56:15
Subject: Re: help

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group