Implementazione della funzionalità di aggiornamento in blocco e le sue compensazioni

1

La funzionalità da implementare è consentire a un utente di selezionare gli articoli e applicare l'aggiornamento dei dati in blocco. È molto simile alla capacità di JIRA di aggiornare in massa un elenco di problemi selezionati . Nel mio caso:

  • I iterate sugli articoli,
  • e per ogni articolo, chiamo semplicemente il metodo esistente usato per aggiornare individualmente un oggetto.

Prendi nota, non posso farlo a livello di sql (ad esempio, aggiornamento batch SQL) in quanto la logica di business è in java.

Evidentemente, per le prestazioni , sarà più lento dato che un utente decide di aggiornare più elementi, quindi puoi aspettarti velocità = # di articoli * tasso di transazione. Quindi, in effetti, l'aggiornamento di un articolo individualmente dovrebbe essere la stessa velocità di un aggiornamento di massa di un elenco in cui l'elenco contiene un singolo elemento. Va bene, poiché è un trade-off .

La mia altra preoccupazione tuttavia è questa: il metodo utilizzato per aggiornare individualmente, rimarrà invariato, e verrà semplicemente richiamato dall'aggiornamento collettivo più volte in base al numero di elementi selezionati; questo metodo acquisisce i blocchi alle tabelle coinvolte fino al termine della transazione. Ciò, in effetti, causerebbe il blocco per molto tempo se ci fossero più elementi da aggiornare; quindi un utente non sarebbe in grado di utilizzare la vista e la pagina di ricerca che recupera dalle tabelle bloccate. È un trade-off che potrebbe non essere accettabile come il primo punto di cui ho discusso sopra.

Sono conflittuale, dato che la natura del metodo esistente per l'aggiornamento individuale di un oggetto è in realtà l'acquisizione di blocchi e non suppongo di toccare quel codice. Dovrei solo riutilizzare quel metodo, chiamandolo più volte per implementare l'aggiornamento collettivo. Questo secondo compromesso è qualcosa che non possiamo bypassare, è un compromesso valido?

Nota anche che non sono un esperto di transazioni e blocchi.

    
posta Carlos Jaime C. De Leon 21.05.2012 - 07:27
fonte

1 risposta

3

Sicuramente puoi utilizzare SQL e gli aggiornamenti collettivi è una di quelle aree in cui può essere una soluzione superiore (in termini di prestazioni) rispetto a un livello ORM o l'attivazione di più piccoli aggiornamenti (con un Transazione sovrascritta).

È il costo di molte chiamate di rete rispetto a una dichiarazione di aggiornamento più ampia.

Devi misurare la differenza di prestazioni, ma suppongo che il tuo I / O attraverso la rete sia il collo di bottiglia più grande.

In termini di serrature / txns, ecc. Tratteremo con cura i limiti di questi. Potresti scoprire che sei in grado di ridurre il sovraccarico di Txn. Usare Txns in stile AOP aiuta qui, cioè iniettando l'inizio e la fine di un txn esattamente ai punti che ti servono e non più.

    
risposta data 21.05.2012 - 09:15
fonte

Leggi altre domande sui tag