Subject | RE: [IBDI] Firebird 1 |
---|---|
Author | Paulo Gaspar |
Post date | 2001-06-05T14:28:11Z |
answer inline:
cover the reasons NOT to cache data - either on a Database Server or in an
App Server.
Sessions are long enough to make it possible to have hundreds of thousands
of them simultaneously open. having all the session data in memory can
become impossible and storing it somewhere else adds up to make serving a
request slower. When possible, I do NOT keep ANY session information.
Have fun,
Paulo Gaspar
> -----Original Message-----There is usually a good enough ORDER BY somewhere. Me previous postings
> From: David Jencks [mailto:davidjencks@...]
> Sent: Friday, June 01, 2001 1:57 PM
>
>...
>
> I think you have come up with a conclusive reason to use the app server
> approach of getting the complete list into a session and parcelling out
> numbered rows from it.
>
> Why? there is no reason to expect the db to return the rows in the same
> order on repeated query executions if all the columns in the order by set
> are not sufficient to distinguish rows.
cover the reasons NOT to cache data - either on a Database Server or in an
App Server.
> ...One wants to keep the data assigned to each session as low as possible.
>
> Or in a session on the app server
Sessions are long enough to make it possible to have hundreds of thousands
of them simultaneously open. having all the session data in memory can
become impossible and storing it somewhere else adds up to make serving a
request slower. When possible, I do NOT keep ANY session information.
Have fun,
Paulo Gaspar