Have you looked at the LISTEN and NOTIFY sql commands in Postgres? I
know the jdbc driver has some support for them, but I haven't ever tried
to use them so I don't know how or if they work through jdbc.
thanks,
--Barry
Per-Olof Norén wrote:
> ----- Original Message -----
> From: "Jean-Christophe ARNU" <arnu@paratronic.fr>
> To: <pgsql-jdbc@postgresql.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
>
>