Come viene KODO JDO distribuito le prestazioni della cache?

Question

Qualcuno ha esperienza con meccanismo di cache distribuita di KODO JDO? Vorrei sapere:

1) qual è la latenza come tra gli aggiornamenti cache distribuita (quindi se due utenti stanno colpendo due cache separate cioè su due JVM diverse e utilizzano gli stessi dati e uno fa un aggiornamento, quando sarà l'altro utente, utilizzando l'altra cache, vedere l'aggiornamento?)

2) quanti dati verranno trasferiti tra JVM? se un aggiornamento è fatto per una cache, vuol semplicemente dire agli altri le cache per rilasciare gli oggetti dicendo che le chiavi primarie degli oggetti per irrigare? (Preoccupazione è il traffico di rete / overhead di gestione della cache distribuita)

3) quando si hanno i feed esterni di aggiornamento del database per tutto il giorno (vale a dire senza che entra attraverso l'applicazione), come è facile invocare esternamente un flush della cache?

La nostra applicazione viene eseguita in un cluster Weblogic di 12 JVM e stiamo prendendo in considerazione consentendo la cache distribuita per aiutare con le prestazioni provenienti dai grandi grafi di oggetti di essere tirato dalla nostra banca dati - che sono attualmente non cached-- ma vorrei sapere un po ' esperienza del mondo reale con # 1,2, e 3. Grazie.

Answer 1

Questa è una risposta parziale, ma credo ancora utile (da http://docs.oracle.com/cd/E13189_01/kodo/docs303/ref_guide_cache.html ):

  

Quando utilizzato in combinazione con un kodo.event.RemoteCommitProvider, commit informazioni sono trasmesse al altre JVM tramite JMS o TCP, e le cache remote sono inficiate base a queste informazioni.

Non è precisato se questo significa che il commit è incluso come parte della transazione originale (si spera) o e / ciò che il ritardo o il sovraccarico è con questa operazione e come ben si scale (per esempio come o lo fa eseguire se si sta coordinando 15 JVM e si dispone di più utenti aggiornano gli stessi dati)