ユーザー管理ツールの一括挿入機能を作成する必要があります。Spring LDAP を使用して小さな社内ライブラリを構築しましたが、シングル ユーザー管理 (CRUD) ではすべて正常に動作します。
一度に何百ものレコードを挿入し、問題が発生した場合はロールバックしたいと考えています。
データベースに存在するように LDAP でトランザクションを作成する方法はありますか?
アイデアをありがとう。
ユーザー管理ツールの一括挿入機能を作成する必要があります。Spring LDAP を使用して小さな社内ライブラリを構築しましたが、シングル ユーザー管理 (CRUD) ではすべて正常に動作します。
一度に何百ものレコードを挿入し、問題が発生した場合はロールバックしたいと考えています。
データベースに存在するように LDAP でトランザクションを作成する方法はありますか?
アイデアをありがとう。
これは @adrianboimvaser のフォローアップです。
Spring LDAP トランザクション サポートは XA トランザクションではなく、「論理的な」補償トランザクションを使用しているため、LDAP のロールバックは LDAP に対する補償アクションになることに注意してください。これはトランザクションなしよりも改善されていますが、これは「データベースに存在するような」典型的なトランザクションと同じではないことに注意してください。つまり、トランザクションのACIDプロパティはサポートされていません。
同じ論理トランザクションが使用されていても、これは JTA XA トランザクションではないことに注意してください。2 フェーズ コミットは実行されないため、コミットとロールバックは予期しない結果をもたらす可能性があります。
例: LDAP に 100 エントリを追加する場合、各レコードは 1 つずつ LDAP に追加されます。最後の追加が失敗した場合、ロールバック アクションにより、トランザクション内で以前に作成された 99 個のエントリが削除されます。ただし、何らかの理由で (ネットワーク接続が LDAP に接続されていないために 100 番目のエントリが失敗した場合など)、最初の 99 エントリを実際に削除できない場合は、トランザクションをロールバックしようとしても、データベースと LDAP。つまり、LDAP には (削除できなかったため) 99 個のレコードがあり、データベースには存在しません (これらのレコードは挿入されなかったか、実際にロールバックされたため)。
あなたの状況はわかりませんが、LDAP に頻繁に大規模な更新を行う場合は、実際のデータベースを使用してトランザクションの頭痛を回避し、パフォーマンスを最適化することを検討することをお勧めします。LDAP は比較的遅い書き込みで高速な読み取り用に設計されているためです。