Holding collections in memory, good or bad idea?
-
Hi, I have several collections which are used many times within my application. These collections (which are mainly generic lists) are collections of user-defined objects populated with data from a database, objects instantiated form classes such as regions, ethnicities, disabilities etc. Is it a good idea to build these collections when the application starts and hold them in memory while the application is running, or would it be better to build them when required then release them when done resulting in many database calls. Thanks in advance.
-
Hi, I have several collections which are used many times within my application. These collections (which are mainly generic lists) are collections of user-defined objects populated with data from a database, objects instantiated form classes such as regions, ethnicities, disabilities etc. Is it a good idea to build these collections when the application starts and hold them in memory while the application is running, or would it be better to build them when required then release them when done resulting in many database calls. Thanks in advance.
Retaining the lists in memory, I do it all the time. How do you deal with the user adding to the list. I have a static class MasterTables with a property for each table, in the getter if there is no table I get the data from the database, this requires 1 call. If the user changes the master table data I simply set the mastertable property to null, next time it is requested a new copy is loaded. This gets away from the initial hit when starting the app, loading all those master tables can be a noticable delay on the load. I know it can be done in a non ui thread but the master tables style suits me admirably.
Never underestimate the power of human stupidity RAH
-
Retaining the lists in memory, I do it all the time. How do you deal with the user adding to the list. I have a static class MasterTables with a property for each table, in the getter if there is no table I get the data from the database, this requires 1 call. If the user changes the master table data I simply set the mastertable property to null, next time it is requested a new copy is loaded. This gets away from the initial hit when starting the app, loading all those master tables can be a noticable delay on the load. I know it can be done in a non ui thread but the master tables style suits me admirably.
Never underestimate the power of human stupidity RAH
Ok great, thanks for the tip, sounds like a good idea and one I will definately use :thumbsup:
-
Retaining the lists in memory, I do it all the time. How do you deal with the user adding to the list. I have a static class MasterTables with a property for each table, in the getter if there is no table I get the data from the database, this requires 1 call. If the user changes the master table data I simply set the mastertable property to null, next time it is requested a new copy is loaded. This gets away from the initial hit when starting the app, loading all those master tables can be a noticable delay on the load. I know it can be done in a non ui thread but the master tables style suits me admirably.
Never underestimate the power of human stupidity RAH
One consideration to make, if you edit the data, your local copy is still valid, but if many users use the program and they have a locally stored copy that is different to yours things get out of sync. You can keep a record of when you last loaded the table from the database, and also a record in the database of the last time the data was updated. This will mean you have to check you have the latest version each time, which is a database call, but you will only get the data if it has changed since you last got it. Only really an issue with a multi user application.
-
One consideration to make, if you edit the data, your local copy is still valid, but if many users use the program and they have a locally stored copy that is different to yours things get out of sync. You can keep a record of when you last loaded the table from the database, and also a record in the database of the last time the data was updated. This will mean you have to check you have the latest version each time, which is a database call, but you will only get the data if it has changed since you last got it. Only really an issue with a multi user application.
Ok thanks, good point! It is a multi-user application, however the lists in question are probably not going to get modified very often. The lists hold data such as ethnicities, regions etc, which are fairly static. But thanks for pointing that out, something I hadn't considered but will bear in mind in the future :)
-
One consideration to make, if you edit the data, your local copy is still valid, but if many users use the program and they have a locally stored copy that is different to yours things get out of sync. You can keep a record of when you last loaded the table from the database, and also a record in the database of the last time the data was updated. This will mean you have to check you have the latest version each time, which is a database call, but you will only get the data if it has changed since you last got it. Only really an issue with a multi user application.
While this is what I call a "technical" issue I have not seen it become a problem in a practical sense (I also currently don't work on transactional systems either). I find that master file information is rarely updated once the system is set up and if I enforce a daily restart it pretty much eliminates the problem. I also tells the users it is a potential issues so they are aware of it.
Never underestimate the power of human stupidity RAH