Session variables of 'XXX' data type should be avoided

Session variables of 'XXX' data type should be avoided

  

Session variables of 'Record' data type with Binary Data, Record, or RecordList attributes should be avoided: one of the session variables that you defined is of the Record or Record List data type and one of its attributes is of the Binary Data, Record, or Record List data type.

You should avoid having a session variable of Record List or Record data type that has an attribute of the Binary Data, Record, or Record List data type.


I vaguely remember session-vars are serialized.deserialized.
I understand what is said, but since it's a warning, how should I handle this warning, and what are effectively the performance issues?

My questions:

- If the session variable is only used for passing data from 1 page to a popup, does it effect overall performance, or just when you are that specific screen(s) ?
- what are the common practices to prevent these warnings (especially practices without having to use a db-table, because it really just is session-stuff)




 

Hi Joost,

Well, the only thing I can add to this discussion is this post I wrote about it a while ago.

I would say that, whenever possible, the best practices are to get the info in the Preparation action of the screen/popup, since SQL Server might even cache most of the frequent requests, so that the performance of DB access is negligible.

Your thoughts?

Regards,

Paulo Tavares
well,

Actually I am uploading an "record2xml" xml-file with a couple of lists, which needs to be compared with the database.
I rather want to compare it straightforward, instead of first placing it in the database, access the popup-window.
get both data from the database and compare the stuff.
what is checked will get merged in the database, the rest will be deleted.
Still struggling with this one.

I have now a couple of record lists in a session variable.
So I have 4 warnings.

1. Are the session variables included in the viewstate?
2. Are session variables transported to the browser as well or are they kept at server?
3. How can I trace the difference in performance if I keep them as is and/move them to the database

Hi Joost,

I don't think the session variables are sent to the page at all. What I believe happens is that, on every request, all your session contents are read off of a DB table in pretty much one lump regardless of you using them or not (although I vaguely remember that they are de-serialized on access only).

Assuming this is the case, this means that having things on a DB explicitly will grant you finer granularity on fetching only what you want rather than loading an opaque thing for which you don't care for much of the contents.

Cheers,


Miguel