Arcadius A. wrote:
> 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.
The business logic in the stored procedure are to much complex to know
what gone be changed... at least I cannot be sure ... And that would be
really complicated and cumbersome tring to guess... and frankly
impossible... It's not an easy problem since the business logic is quite
complicated .. .So lot of stored procedure and lot of SP that calls
others SP.
Thanks for your help
Regards
/David