イントラネットユーザーがデータベースレコードを処理できるようにするシステムがあります。基本的に、レコードはチェックされている/チェックされていないため、それぞれの現在の合計が更新され、別々のセッション変数に配置されてから、別のデータベースに送信されます。時々奇妙なことが起こり、これらのセッション変数の値は2倍（またはさらに悪い）になる可能性があり、私はこれを複製することができませんでした（完全にランダムで幸運にもまれに見えます）。
書き換えの可能性を考えており、Cookieを使用して値を一時的に保存し、強制的に期限切れにしてこれらの値をクリアする方がよいかどうか疑問に思っています。
これらの代わりに、ViewStateはここに適用できますか？私はそれについて簡単に読みましたが、ビューステート値を明示的に設定した経験はありません。
私の主な懸念は、私の変数が同時にシステムを使用している他の誰かの影響を受けていることですが、セッション変数のポイントの一部は、それらが作成されたセッションによってのみアクセス可能であるということだと思いましたか？
ViewStateはデータをポストバックするためにのみ使用され、セッション全体にわたって永続的ではないため、どちらの代わりにもなりません。結局のところ、これは「表示」状態です:)。
セッション変数は実際にはCookieを使用しますが、関連するすべてのデータをCookie内に保存するよりも安全な方法で使用されます。値をCookieに直接保存するだけでも問題ありませんが、少し単純なJavaScriptを使用しているユーザーは、Cookieの内容を変更できます。それがうまくいかない場合は、セッションを使用してください。
生データをCookieに保存する場合と比較した場合のセッションの小さな欠点は、データがサーバーに保存されることです。サーバーはスペースとコンピューティングリソースを消費します。それほど多くはありませんが、トラフィックの多いサイトを作成する場合や、すべてのものとキッチンの流し台をセッション中に保管することを検討している場合は、検討する必要があります。
では、セッションはどのように機能しますか？キーでアクセス可能な、各セッションユーザーに固有のデータを格納します。そのキーは通常、クライアントのマシンのCookieに保存されます。ユーザーがページにアクセスすると、Cookieキーがサーバーに送信され、関連データにアクセスできるようになります。覚えておくべき重要なことの1つは、Cookieのセキュリティがセッションのセキュリティの要であるということです。XSS攻撃に対して脆弱なサイト（他の投稿全体の対象）がある場合、ユーザーは他のユーザーのCookieを盗み、他のユーザーのセッションを識別するIDを持っているため、それらになりすますことができます。
したがって、全体として、どのシステムを使用するかを判断するのは困難です。個人的には、セッションは実装が簡単で、ユーザーが変更可能なデータがないという追加のセキュリティが優れているため、セッションを使用する傾向があります。ただし、最終的には、アーキテクチャを調べて、自分に最適なものを決定する必要があります。