Hannes Landeholm wrote:
Certain function in the application runs a MySQL procedure that updates a
> certain complex selection of products in the products database rendering the
> currently loaded products in memory obsolete since they might have been
> updated.
Then you are caching the wrong data in memory?
Following an update like that one would either have to commit the changes or
rollback. So the data has to be reloaded from the server anyway. You can't rely
on any of the data already loaded.
Joe deploys the application again and can only hope that this was the
only loop that triggered the memory problem and that the application
doesn't crash anywhere else when the products table grows larger.
So you are trying to load lots of unnecessary data from the database through
poor design. Redesign the data so it works properly ... or switch to a database
that handles business logic via triggers properly ;) You should only be
downloading the data you need to look at, leave the volume data on the server.
The majority of my business logic is done in the database (Firebird) and I
simply can't see how I would ever fall into the trap you seem to be creating?
Perhaps I am doing something wrong, but my systems all run multiuser real time
and handle large numbers of records without these sorts of problem.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
