問題タブ [stateless]

単一の乱数ジェネレーター (RNG) を使用して複数の数値を生成することと、ジェネレーターごとに 1 つの数値を生成して破棄することに違いはありますか? 両方の実装で同じようにランダムな数値が生成されますか? これについて、通常の RNG と安全な RNG の間に違いはありますか?

クライアントに代わって乱数のリストを生成することになっている Web アプリケーションがあります。つまり、数字は各クライアントの観点からランダムに見える必要があります。これは、クライアント セッションごとに個別のランダム RNG を保持する必要があるということですか? または、すべてのセッションで 1 つの RNG を共有できますか? または、リクエストごとに RNG を作成して破棄できますか?

更新: この質問は、ランダム シーケンスのサブセットもランダムですか? に関連しています。

私はdjangoを使用しており、GETフォームと約30個のチェックボックスを備えた静的Webページを持っています。ユーザーがさまざまなボックスを選択し、検索をクリックすると、データベースからの結果がテーブル内の同じページに返されます。ただし、HTML はステートレスであるため、すべてのチェックボックスがオフになっています。

チェックボックスの状態を「記憶」する最も簡単な解決策は何ですか? 私はdjangoのドキュメントを調べましたが、例では単一のテキストフォームに変数とIFを使用しているだけです. 確かに、各チェックボックスがquerydictに設定されているかどうかを確認する必要はありませんか? また、私のフォームは、django フォームを使用するのではなく、カスタム作成されました。

最終的に、ページにJSONを使用してテーブルのみを更新することを計画していましたが、それでこの問題は解決しますが、以前の検索で戻るボタンが機能しないなど、さらに多くのことが導入されるかどうかはわかりません.

私のアプリケーションにはステートレス EJB があります。そして今、ステートフルを介していくつかのデータベース操作を行う必要があります。このステートレス EJB は、ステートフルな接続を開く DB ユーティリティにアクセスできますか? これにより、設計/パフォーマンスの問題が発生しますか?

私はユーザーが社会的に交流できるオンラインシステムに取り組んでいます。もちろん、実際にオンラインであるユーザーを識別できることが重要になります。HTTPがステートレスであることと、セッションの使用について知っているので、ユーザーの最後のアクティブ時間を任意の有効期限と比較することによってこれを実現する必要があります。

私の最終的な質問はこれに帰着します：既存のメンバーテーブル（、、、など）にいくつかのフィールドを追加する必要がlast_active_timeありis_user_onlineますhide_online_statusか、それともこの情報を別のテーブルに保持するのが最善でしょうか？私の最初の考えは、単純化のために既存のテーブルを使用することです。複雑さのレベルは別として、一方と他方の長所/短所は何ですか？

少し助けてください。

次の機能を持つステートレスサーバーを設計しています。

1. クライアントはサーバーにジョブを送信します。
2. サーバーがジョブを実行しようとしている間、クライアントはブロックされます。
3. サーバーは、ジョブを実行するために1つまたは複数のスレッドを生成します。
4. ジョブは終了するか、タイムアウトするか、失敗します。
5. （結果に基づいて）適切な応答が作成され、クライアントのブロックが解除され、応答がクライアントに渡されます。

これが私がこれまで考えてきたことです。

1. クライアントはサーバーにジョブを送信します。
2. サーバーはIDをジョブに割り当て、ジョブをキューに配置してから、クライアントを別のキュー（ブロックされる場所）に配置します。
3. ジョブを実行し、結果をフェッチして適切に応答を作成するスレッドプールを用意します。
4. IDに基づいて、キューからクライアントを選択し（それにより、ブロックを解除し）、応答を返し、送信します。

手順1、3、4は非常に簡単に思えますが、クライアントをキューに入れてブロックする方法についてのアイデアはありません。また、この子犬をデザインするのに役立つポインタをいただければ幸いです。

乾杯

ファクトリ クラスにアクセスする必要があるステートレス セッション Bean があります。このファクトリ クラスは、SLSB で静的メンバーまたはインスタンス メンバーとして宣言するのが最善ですか? SLSB が再利用されるため、リクエストごとに 1 つのインスタンスではなく、Bean ごとに (インスタンス メンバー オプションを使用する場合) ファクトリのインスタンスが 1 つだけ作成されるというのは正しいでしょうか?

先日、OAuthに関する記事を読みました。特に、一連のリクエスト中にクライアントとサービスプロバイダーの間で交換されるトークンについて説明しました。

この記事では、OAuthが承認レイヤーとしてRESTfulAPIで非常に人気があることにも言及しています。私が理解したように、RESTは完全にステートレスに保つ必要があります。

質問：この繰り返されるトークン交換魚雷RESTの「ステートレス」の原則ではありませんか？私見では、トークンは一種のセッションIDと見なすことができますね。

大規模なプロジェクトに取り組み、依存関係の注入を管理するためにSpringを使用し始めました。ほとんどの開発者はステートフル クラスのコーディングから移行しているため、一部のステートレス Bean には、それ自体がステートフルなインスタンス変数が実際に含まれていることがわかりました。

私が間違っている場合は修正してください。Spring xml で定義されたすべてのステートレス Bean が実際にステートレスであることを確認するための単体テストを作成するのはそれほど難しいことではありません (つまり、Bean には、Spring xml で定義されていないインスタンス変数があってはなりません)。 . 自分で書いてみる前に、それを確認するための既存のツールがあるかどうか疑問に思いますか?

どうも

私はEJBが初めてです。同じ Bean でメソッドを呼び出す前に、リモート ステートレス Bean のメソッドを呼び出して値を設定する必要があります。最初のメソッド呼び出しで設定された値は、2 番目のメソッドで使用できる必要があります。ステートレス Bean は、次の呼び出しのためにインスタンス変数の値を保持できないことを知っています。Bean をステートフル Bean にすることなく、Bean メソッドで値を使用できるようにする代替手段はありますか。微調整のヒントはありますか？