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.