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

Re: implementing asynchronous notifications PLEASE CONFIRM MY

From: "Arcadius A(dot)" <arcadius(at)menelic(dot)com>
To: David Gagnon <dgagnon(at)siunik(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: implementing asynchronous notifications PLEASE CONFIRM MY
Date: 2005-08-29 03:34:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
David Gagnon wrote:

> Hi ,
>   Thanks for your answer, see my answer below..
>> David Gagnon wrote:
>>> Hi all,

>> However I do not know your exact requirement, if I were to solve such 
>> a problem, I would not try to put any overhead on the DB server; 
>> after all, the purpose of caching is to give a brake to the DBServer.
>> In fact, the easiest way to have the cache in sync with the DB is to 
>> have a kind of Facade , a unique class, with static methods for 
>> reading/writing data for both the cache and the DB.
>> Using a single class for reading/writing , you won't need the DB to 
>> notify  you of changes since all call go through your facade, that 
>> means that you know when things are being changed and can take action.
>> However, your requirements my be different.
>> Regards. \

> The big problem is that when a user launch a stored procedure.. chance 
> are that he will consult the other data right after the completion of 
> the stored procedure.  If data have not been updated in the cache I 
> will display invalid data :-(
If the user is calling the SP from the same Java app , then , what I 
said before is still valid.
The method which calls the SP should clear/invalidate the cache .
So, the next time the user tries to view data, as the cache is 
empty/invalidated , new stuff should be loaded from the DB.



In response to


pgsql-jdbc by date

Next:From: Clemens EissererDate: 2005-08-29 11:28:23
Subject: Re: NullPointerException when calling ResultSet.absolute(int)
Previous:From: Peter WilkinsDate: 2005-08-29 00:23:08
Subject: username and password for postgresql jdbc FTP site

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