Caching DataSet and DataAdapters 1

[lanm]

I'm working through the MCAD training, and can't seems to get a dropdownlist to populate from a cached dataset:

**********
Here's the code on the first page:
Private Sub Page_Load(....)
If Not IsPostBack Then
AddtoCache("adptCalls", DA1)
AddtoCache("adptContactTypes", DA2)
AddtoCache("adptContacts", DA3)
'Fill data sets and add them to Cache
DA1.Fill(DsCalls1)
AddtoCache("DSCalls", DsCalls1)
DA2.Fill(DsContactTypes1)
AddtoCache("DSContactTypes", DsContactTypes1)
DA3.Fill(DsContacts1)
AddtoCache("DSContacts", DsContacts1)
End If
End Sub

Sub AddtoCache(ByVal Name As String, ByVal Item As Object)
'if item already in cache, simply return
If Not IsNothing(Cache(Name)) Then Return
'Otherwise cache item for 20min w/ sliding expiration
Cache.Add(Name, Item, Nothing, DateTime.MaxValue, System.TimeSpan.FromMinutes(20), Caching.CacheItemPriority.Default, Nothing)
End Sub

**********
The second page has:
Private Sub Page_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
' Get the Cached variables.
adptContacts = Cache("adptContacts")
dsContacts = Cache("dsContacts")
dsContactTypes = Cache("dsContactTypes")
If Not IsPostBack Then
' Bind to data -- populates lists.
drpContactTypes.DataSource = dsContactTypes
drpContactTypes.DataTextField = "ContactType"
drpContactTypes.DataValueField = "ContacTypeID"
drpContactTypes.DataBind()
drpStates.DataBind()
End If
' If there was an unhandled error, display it.
If Session("Error") <> "" Then
litStatus.Text = Session("Error")
' Reset the error message.
Session("Error") = Nothing
End If
End Sub

 

[BoulderBum]

The cache dictionary is case-sensitive and you're using:
"DSContactTypes"
to add an item on page one and
"dsContactTypes"
to retrieve the item on page two.

Out of curiosity, why are you caching the DataAdapter?

 

[lanm]

I've been asked that on another forum about the adapter. The "lab" for this chapter has you cache the connection, adapter, and the dataset.

Thanks for the help!

 

[Isadore]

BB - this is an interesting topic; when and under what conditions to Cache, say, a DataSet, or even a DataAdapter, etc.

What is the difference in Server resources, for example,
between the following:

1) say a connection is available in the connection pool, and you hit a table using a reader extracting a DataSet consisting of 15 fields with 100 records; as compared with

2) maintaining a Cache of the same dataset, publically available, etc. Of course this would all tie into actual scaling conditions -- so, a number of variables.

Another question that comes to mind is this; are there any advantages to Caching certain objects thereby limiting perhaps the number of actual objects one does create (from Command objects, to Connection objects). Could there be a 'Memory Leak' advantage to this, e.g.?

Anyway, good topic and thought I might respond.

 

[BoulderBum]

I think, rule of thumb, the developer wants to cache frequently used objects/data that are relatively expensive to create/ retrieve and aren't expected to change.

I think it makes sense in some circumstances to cache a frequently used DataSet (e.g. one used to populate a DropDownList on a frequently visited page) because instead of 1. connecting to the database, 2. having the database run a query, 3. having the database return the results over the wire and 4. loading up the DataSet, you're simply getting the DataSet stored in local memory and binding. The overhead saved could be considerable!

Then again, the sacrifice, as you point out, is web server memory, so you don't want to go overboard with caching (it's actually said to be one of the bigger sources of performance problems)!

As far as caching ADO.NET command/adapter/connections, I don't really see the reasoning behind it. Allocating memory is cheap, but more importantly, you often want to vary parameters in a command and don't want to have multiple users manipulating the same command's parameter values at the same time, which will happen if they both reference the cached object! Additionally, sharing the same connection (which is implicit in caching those objects) will likely crash the commands!

I think instead of caching the above ADO.NET objects, the developer would be better off implementing a factory or prototype pattern to pump out new, independent, but similarly configured instances. It conserves memory and ensures thread-safety.

 

[lanm]

BoulderBum,

Thanks for the extra eyes on that one! It was the case sensitivity.