Application Scope in a Web App

[sde]

Is it a good Idea to use Application variables for data which is not changed very much? Let's say for a web app that has Users and User Groups, UserGroups would not change very much.

Query times are my primary concern. 600-1000ms is what I'm getting per query. When I am working with a few different objects which each run queries, it adds up.

[Belisarius]

I honestly don't know, I haven't fiddled around with scoping much. It might reduce overhead, as application scope can be roughly equated to static scope, so you'd create the objects few times.

[npa]

well, just be aware that if its global (static, public)
you will have to be careful of synchronisation issues when
accessing / deleteing from it...

i generaly wouldn't bother getting something out of a db
and storing it in a variable like that unless the query was
*REALLY* slow and the difference would significantly improve
the speed of my app, i can't imagine these would be true
in your case, so I would not do it.

however, if you are constantly trying to query the group
of your user, or something, that isn't a great idea ... I
would store all user details in some session object - not
sure if you are doing that.

[Belisarius]

Another thing is that recalling our conversation about DB connection pooling, you shouldn't have that much overhead to begin with in regards to executing queries.

[sde]

right, i got pooling happening. it is the actual query that is taking up that time. if pooling wasn't happening, then it would tack on about another 2-3 seconds.

[SpaceMonkey]

Quick stab at this without deep thought, so here goes...

Make your UsersGroups class such that it follows the Singleton Pattern. This is similar to global variables, but different. There are many articles about the Singleton Pattern... Google is your friend!

You'll have one instance for you whole app, created the first time you access the instance, which should accomplish what you are looking for without using Application Scope.

'Freshness' check
When the class is first instantiated, you can make the neccessary calls to the database that would populate the UsersGroups data appropriately. At this time, record the system time in a variable to determine how 'old' the data is.

When you make calls to get the UsersGroups data, check that the data hasn't gone 'stale' by comparing the current system time with the time of the last data 'refresh'. If the difference is outside the time period you feel is acceptable (defined as a static final), then re-populate the data from the database before returning.

Refresh flag
You should also define a public boolean called 'refreshNeeded' (or something similar) that you can set from any class that modifies the UsersGroups data in the database.

Like the Freshness check, you would need to check this flag before returning to make sure you aren't using 'stale' data.

Caveat
As usual, Your Mileage May Vary...
(meaning, there are pro's and con's to this approach that depend on your environment and use cases)


Pro - This essentially caches your data and should minimize database access, which is what you were trying accomplish

Con - Client's are disconnected from the data. When someone submits an update to the data, there is a chance (how small or large depends on your implementation) that the data you're changing has already been updated by someone else, so you need to handle this. Also, due to the nature of the web, any clients that already have this data will have out-dated data. This will also have to be dealt with appropriately when submitted.


Overall, if the data you are looking to 'cache' changes infrequently and you can control how these changes are made, this should work well for you with little hassle.