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

Re: Constant "JTable" update

From: "Dave Cramer" <Dave(at)micro-automation(dot)net>
To: 'Per-Olof Norén' <pelle(at)alma(dot)nu>, "'Jean-Christophe ARNU'" <arnu(at)paratronic(dot)fr>, <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Constant "JTable" update
Date: 2001-11-09 14:18:56
Message-ID: 023c01c16929$784e5660$c201a8c0@inspiron (view raw or flat)
Thread:
Lists: pgsql-jdbc
Is there anything in the jdbc spec which supports this?

I have had a quick look, and haven't found anything.

I suppose this could be a postgres specific extension if it doesn't
exist in the database

Alternatively instead of getting all the rows to the database you could
do this another way


Create the table with a sequential id

Ie create table foo (id serial, ....)

Get the largest id  of the rows

while(1){
	newmax = 0;

	select max (id) from foo;

	if max > newmax, then you have more data

	select * from table where id > max

	newmax = max
}

This is just pseudo code, but it should be close

Dave 
-----Original Message-----
From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Per-Olof Norén
Sent: November 9, 2001 8:05 AM
To: Jean-Christophe ARNU; pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] Constant "JTable" update



----- Original Message -----
From: "Jean-Christophe ARNU" <arnu(at)paratronic(dot)fr>
To: <pgsql-jdbc(at)postgresql(dot)org>
Sent: Thursday, November 08, 2001 10:38 PM
Subject: [JDBC] Constant "JTable" update


> The straightforward solution seems to have database listeners on the
> table that wakes-up a notifier in the java program. But such kind of
> mechanism seems not to be implemented in the JDBC API (up to my small
> knowledge).

I haven´t seen such a mechanism, either :-)


> The second tortuous solutions (the one I use) is to query the database
> relatively often to get the freshest results. This is quite bandwidth
> consumming (assuming that some users should use a quite small
bandwidth
> connection). Using this kind of solution makes the Java application
> slow...
First of all, this is how I interpreted your config.
You do a executeQuery once the rendering of the chart is done for one
execution?
And you process the entire ResultSet everytime, even though no changes
are
made?

If this is the case, I would suggest a change in the following
direction:
1. Create a little status table containing just one column: create table
last_change (lastchange datetime). Also add one row to the table
2. Create a trigger on the measurer table, that updates the date of the
status table.
3. Design your algorithm something like this


check status by executing a select on status table.

if changed {
    store the date from status query
    execute data query
    render chart
}

This would reduce the bandwith by not sending the resultset when no
changes
are made.

By measuring the average change in time between , say the last five
updates
to the status table, you
could even put the rendering of the chart in its on thread and let it
sleep
a little shorter than the average time

Regards,
Per-Olof Norén




---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



In response to

pgsql-jdbc by date

Next:From: GuidoDate: 2001-11-09 16:41:59
Subject: Re: JDBC Connection
Previous:From: Daniel GermainDate: 2001-11-09 13:50:43
Subject: Re: ResultSet.getDate failure with timestamp column

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