Какова производительность распределенного кэша KODO JDO?

Question

Есть ли у кого-нибудь опыт работы с механизмом распределенного кэша KODO JDO?Я бы хотел знать:

1) какова задержка между обновлениями распределенного кеша (например, если два пользователя обращаются к двум отдельным кешам, т.е.на двух разных JVM, которые используют одни и те же данные, и один выполняет обновление, когда другой пользователь, использующий другой кеш, увидит обновление?)

2) сколько данных будет передаваться между JVM?если обновление производится в одном кеше, просто ли оно сообщает другим кешам удалить объекты, сообщая ему первичные ключи объектов для очистки?(проблема связана с сетевым трафиком/накладными расходами на управление распределенным кешем)

3) когда у вас есть внешние каналы, обновляющие вашу базу данных в течение дня (т.е.не поступает через ваше приложение), насколько легко вызвать очистку кэша извне?

Наше приложение работает в кластере Weblogic из 12 JVMS, и мы рассматриваем возможность включения распределенного кэша, чтобы повысить производительность за счет больших графов объектов, извлекаемых из нашей базы данных, которые в настоящее время не кэшируются, но хотелось бы узнать некоторые реальные факты. опыт работы с номерами 1,2 и 3.Спасибо.

Answer 1

Это частичный ответ, но я считаю, что он все еще полезен (Из http://docs.oracle.com/cd/E13189_01/kodo/docs303/ref_guide_cache.html):

При использовании в сочетании с kodo.event.RemoteCommitProvider информация о фиксации передается другим JVM через JMS или TCP, а удаленные кэши становятся недействительными на основании этой информации.

Не указано, означает ли это, что эта фиксация включена как часть исходной транзакции (можно было бы надеяться) или и/или каково время задержки или накладные расходы при этой операции и насколько хорошо она масштабируется (например,как это работает, если вы координируете 15 JVM и несколько пользователей обновляют одни и те же данные)