Я полагаю, что Apache DS поддерживает использование элементов управления синхронизацией контента, как определено в RFC 4533. Эти элементы управления могут использоваться для реализации своего рода репликации или синхронизации данных между системами, и кэширование является довольно распространенным использованием этого. UnboundID LDAP SDK поддерживает эти элементы управления (http://www.unboundid.com/products/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/ContentSyncRequestControl.html). Я бы порекомендовал взглянуть на эти элементы управления и информацию, содержащуюся в RFC 4533, чтобы определить, может ли это быть более подходящим.
Другой подход может заключаться в том, чтобы проверить, поддерживает ли Apache DS журнал изменений LDAP (например, в формате, описанном в draft-good-ldap-changelog). Это позволяет вам получать информацию о записях, которые были изменены, чтобы их можно было обновить в вашей локальной копии. Периодически опрашивая журнал изменений для поиска новых изменений, вы можете использовать информацию об изменениях в своем собственном темпе (включая те, которые могли быть сделаны, когда ваше приложение находилось в автономном режиме).
Хотя постоянный поиск может работать в вашем случае, есть несколько проблем, которые могут сделать его проблематичным. Во-первых, вы не получаете никакого контроля над скоростью, с которой обновленные записи отправляются вашему клиенту, и если сервер может применять изменения быстрее, чем клиент может их использовать, то это может перегружать клиента (что наблюдалось в ряде реальных случаев). Во-вторых, постоянный поиск позволит вам узнать, какие записи были обновлены, но не какие изменения были внесены в них. В случае кеша это может не иметь большого влияния, потому что вы просто замените свою копию всей записи, но в других случаях это менее желательно. Другая большая проблема заключается в том, что постоянный поиск будет возвращать информацию только об обновлениях записей, когда поиск был активным. Если ваш клиент выключен или по какой-то причине соединение становится недействительным, то нет простого способа получить информацию о любых изменениях, пока клиент находился в этом состоянии.
Кэширование на стороне клиента, как правило, плохо по многим причинам. Он может предоставлять устаревшие данные приложениям, которые могут вызвать неправильное поведение или в некоторых случаях создавать угрозу безопасности, и это абсолютно огромный риск для безопасности, если вы используете его для аутентификации. Это также может представлять угрозу безопасности, если не все клиенты имеют одинаковый уровень доступа к данным, содержащимся в кэше. Кроме того, реализация кеша для каждого клиентского приложения не является масштабируемым решением, и если вы попытаетесь разделить кеш между несколькими приложениями, вы можете просто сделать его полным экземпляром сервера каталогов. Гораздо лучше использовать сервер, который может просто обрабатывать желаемую нагрузку без какого-либо дополнительного кэширования.