Re: Problem with JDBC MSSQL
From: dar7yl (no_reply_at_accepted.org)
Date: 03/12/05
- Next message: slothbear: "Re: simple persistence without databases"
- Previous message: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
- In reply to: Robert Klemme: "Re: Problem with JDBC MSSQL"
- Next in thread: Daniel Hagen: "Re: Problem with JDBC MSSQL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 12 Mar 2005 03:22:27 GMT
"Robert Klemme" wrote in message
>> > However, I recommend not to use JDBC from an applet. Better use a
>> > specialized protocol between applet and server (a simple solution
>> > could be to send serialized objects via HTTP).
> "dar7yl" schrieb im Newsbeitrag
>> I don't agree with your recommendation. I have had no problem using
>> JDBC from an applet.
> Well, I didn't say it's impossible.
>
>> Your idea of using a specialized protocol between applet and server just
>> adds a layer of complexity to an already obfusticated concept.
>
> I don't know which of the concepts involved you call "obfuscated". Apart
> from that, you forget to mention that an additional layer has indeed
> benefits. Layering is a common technique in the area of software
> engineering to separate concerns and keep things manageable. For example
> it gives you more flexibility and control over communication which is
> important for an applet that is used via a WAN as the internet (=
> potentially slow and high latency). And you don't have to load driver
> classes and you can easily use another persistent storage instead of JDBC.
>
>> A properly designed application can operate
>> quite well as a database client.
>
> You have to keep in mind that you have no control at all about the way a
> JDBC driver talks to the database. There might well be a lot of short
> messages which can lead to a considerable slowdown of the applet's
> operation of used via a WAN.
IMHO, "Enterprise" is a term used when you split an application into two
parts so you can charge twice as much as the old one, and get half the
performance, in twice the time.
Yes, you could have dismal performance if you don't understand how
the jdbc driver is communicating with the database server. However,
it's been my experience that a modern database driver has excellent
performance over the net. When you get down to it, the information
you want to display is usually what you have scraped off the database.
If you compose your queries properly, and pay attention to the
capabilities of the database, the actual amount of data transferred can
be quite efficient. In my experience, most of the lag time I observe is
due to database processing; not transfer time. The response times
are quite acceptable in most cases.
Most modern drivers are quite good at transferring the data back and
forth between the client and the server. You are still going to get
database
latency no matter what level you are talking at. Also, with middleware, you
have to translate the data into another format, which can add bulk without
corresponding increases in functionality.
I have had good performance running applications in a variety of
environments.
Of course, best performance is running on the local machine, with LAN
running
a close second. Even running on a WAN using VPN over the internet is
quite acceptable (We regularly run between Vancouver (BC) and Prince Rupert
using SonicWall VPN over ADSL). The response is still comparable to the old
VB
program which used a local Access database. In some instances it has sped
up,
which I attribute to MySQL's better handling of complex joins.
regards,
Dar7yl
- Next message: slothbear: "Re: simple persistence without databases"
- Previous message: Lee Fesperman: "Re: ODB (Cache?) vs ORM"
- In reply to: Robert Klemme: "Re: Problem with JDBC MSSQL"
- Next in thread: Daniel Hagen: "Re: Problem with JDBC MSSQL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
