Databases
StackOverflow2013
Postsdbo
POWhat is a good way to store large temporary "session" data in a web application
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat is a good way to store large temporary "session" data in a web application
    primarykey
    data
    text
    <p>My company has a 3rd party web service we are designing a front end for. The "objects" used by this web service are very large (and variable depending on the number of sub-entities created). The web service does not expose methods to commit/load sub-entities, only the full object hierarchy.</p> <p>The UI itself is split into many sub screens, and master/detail views to be able to efficiently/easily edit the large amount of data. </p> <p>The issue is where to store all the data you aren't currently looking at.</p> <p>Doing the web service commit takes up to 30 seconds for large records, so it is not feasible to use the web service for the intermittent data storage. </p> <p>As mentioned, the data can be quite large (multiple megabytes, to possibly a gigabyte of data in the edge cases)</p> <p>This is for ASP.Net 4.0, with a MS-SQL back-end, and a 3rd party SOAP web service. </p> <p>Changing the web service contract is not an option.</p> <p>Here are some ideas we have had. Help me choose, or identify something better!</p> <p>1) The initial developer threw serialized XML into the session (on-machine session). I quickly identified this as problem, as using session in this way could drastically affect performance due to the memory taken up, as well as load balancing issues etc.</p> <p>2) Session server - possible, but requiring additional hardware purchase for this is probably not an option</p> <p>3) SQL session - Performance of storing such a large object?</p> <p>4) Write XML to disk/share (zipped?)</p> <p>5) Write XML to SQL (zipped?)</p> <p>6) SQL relational database - create tables for each entity type. This would allow individual sub-entity load/save which could be great on performance. We are worried about brittleness and maintenance since we do not control the 3rd party service (although we have that issue anyway really, since the GUI also would be brittle)</p> <p>7) viewstate - way too big, perf hit</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USJason Coyne
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. USVS1
      1. VTFavorite
    1. COmaybe you should have a look to json objects http://www.json.org/ it is replacing XML these days. because of the simple notation compared to XML the data volume will decrease too
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. USkasper Taeymans
    2. COThat is a good suggestion, however we have to maintain XML serialization in order to get the web service to work, so JSON would mean maintaining two sets of hydration logic. (even though the XML part is mostly auto-generated).
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. USJason Coyne
    3. COIn your title you said "session" data, which leads me to believe that this information is user-specific in some way. Is that correct?
      singulars
      1. POWhat is a good way to store large temporary "session" data in a web application
      1. USJames Johnson
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload