Minimizzare tavolo stallo nel mio scenario con Oracle e InnoDB

Question

Ho 35 funzioni che l'aggiornamento da 1 a 3 tavole, in una transazione. Tuttavia, essi non si limitano a eseguire gli aggiornamenti, ma lo fanno domande pure.

• Tabella 1 fa aggiornamento fila solo azioni, e alcune query.
• Tabella 2 fa interrogazioni e gli aggiornamenti a livello di riga alle righe esistenti, e, talvolta, elimina e aggiunge righe. Tabella 2 può avere query all'interno della transazione, prima e dopo le eliminazioni di riga e di o inserzioni, e o aggiornamenti.
• Tabella 3 fa gli aggiornamenti di fila in base ai risultati della tabella 2 azioni di cui sopra.

La mia prima azione sarà quella di assicurarsi che i tabella 3 aggiornamenti sono tutti fatti alla fine.

Tabella 1 è indipendente dagli altri 2 tavoli, e, probabilmente, può essere il primo o l'ultimo. Così Tabella 2 deve venire prima della tabella 3 modifiche.

La mia prima preoccupazione è che con tabella 2 azioni, faccio domande, poi gli aggiornamenti, poi più query, quindi ulteriori aggiornamenti a volte. Devo reorg il mio codice non farlo.

La mia seconda preoccupazione è che la tabella 3 è la tavola che con fili servlet deve essere veloce. Tabella 3 è usato semplicemente per le query di per sé. Ma sembra che i blocchi a livello di riga si fermerà le query.

Se devo, posso mettere il codice mantenimento di insiemi tabella descritta sopra in un unico processo di tutto il cluster, da un thread. La velocità degli aggiornamenti non importa. Solo che le query tabella 3 sono veloci. E che non c'è mai alcuna situazione di stallo.

non so le differenze tra Oracle e InnoDB, quindi ho domande lì. (Ho intenzione di passare a Oracle in seguito.)

In sostanza, sto cercando per i puntatori su cosa guardare fuori per. Naturalmente, ho potuto forzare un blocco di tabella completa sulla tabella 2 e poi la tabella 3, all'inizio di ogni funzione di aggiornamento, ma poi il mio Table3 filo interrogazione servlet avrei sofferto. In modo che non sembra una soluzione.

Inoltre, sono preoccupato per solo rispetto al tavolo 2 in sé, che alcune funzioni fanno domande, aggiornamenti in base alla query, nuove query basate sulla aggiornamento, quindi ulteriori aggiornamenti, tra cui scorre risultati attraverso agli aggiornamenti alla tabella 3 . Questo sembra davvero brutto.

raccomandazioni? Andy

Ci potrebbe essere aggiornamenti simultaneo allo stesso file di 2 tavoli, e ho preso cura di colpire le tabelle con gli aggiornamenti nello stesso ordine. Una delle tabelle ha indici 2, e sembra che sia necessario un blocco di tabella per aggiornare l'indice? Alcune delle funzioni di query tabella 1, tabella di aggiornamento 1, quindi opzionalmente interrogazione tabella 2, quindi aggiornare la tabella 2, in un ciclo di ripetizione. Questa tabella contiene tutte le relazioni del bambino genitore in un albero di tutta la mia contenuti, quindi è alta l'aggiornamento volume su tutti gli utenti.

Answer 1

In primo luogo, le query di Oracle (e credo InnoDB) non prendere un blocco a meno che non si utilizza per l'aggiornamento.

In secondo luogo, non ho ricevuto alcuna idea della bilancia applicazione. Quante transazioni concorrenti si aspetta di avere? Si aspetta che siano aggiornando le stesse righe?

Il tipo di applicazione che potrebbero soffrire di deadlock è un sistema di prenotazione o di biglietteria (ad esempio persone che cercano di prenotare gli stessi posti in un teatro), soprattutto in situazioni di alta concorrenza (nuovo spettacolo diventa disponibile per la prenotazione).

Se l'applicazione si adatta questo profilo, allora probabilmente si vuole anticipare le situazioni di stallo. Tuttavia, vorrei almeno prendere in considerazione semplicemente intrappolare l'errore, di nuovo a rotazione e poi ri-provare la transazione. Se si va in maggiori dettagli nelle vostre strutture delle tabelle, relazioni e criteri di aggiornamento, quindi un punto appropriato per la chiusura può diventare evidente.