SELECT FOR UPDATE

[mtozzi]

Il costrutto SELECT FOR UPDATE è indispensabile in molte situazioni applicative in cui si vuole gestire una transazione evitando problemi di concorrenza sugli update. Vi propongo di implementarlo nel visual code in modo completo, attualmente affermate che non è implementato per il DB2, infatti il codice generato da una "select into variables" visual code non cambia con la clausola for update.
Ho notato che per oracle (che tra l'altro ha la stessa sintassi SQL di DB2 per questo comando) una select for upadate viene generata mettendo una clausola OF arbitraria (la prima colonna). Sarebbe meglio a questo punto invece che mettere una colonna a caso o lasciare all'utente la possibilità di specificarla oppure non mettere niente visto che tale clausola è opzionale nel costrutto SQL.

[mtozzi]

Aggiungo che lavorando in java su db2 e specificando la query SELECT FOR UPDATE nel visual code "a mano" con il costrutto SQLQuery non viene preso comunque il lock di tipo esclusivo sul record. Questo comportamento è dovuto all'utilizzo della classe IDCachedRowSet invece che della classe java.sql.Statement per l'esecuzione delle query. Vediamo un esempio java dell'utilizzo di IDCachedRowSet che ho usato per verificare questo comportamento:

Code: Select all

//Instanzio una connessione al database
Connection conn = ...;

conn.setAutoCommit(false);

IDCachedRowSet crs = new IDCachedRowSet();
crs.setCommand("SELECT NM_PROGRESSIVO FROM OPERGEST.PROGRESSIVI WHERE CD_PROGRESSIVO='PROVA' FOR UPDATE OF NM_PROGRESSIVO");
crs.execute(conn);
crs.next();
int progressivo = crs.getInt(1);      

conn.commit();


L'esecuzione di questo codice non crea un lock esclusivo sul recod in questione quindi esecuzioni concorrenti non vengono bloccate.
Eseguendo la stessa query tramite la classe java.sql.Statement il comportamento è quello giusto, cioé si genera un lock esclusivo sul record e le esecuzioni concorrenti sono bloccate. Vediamo il codice in questo caso:

Code: Select all

Connection conn = ...;
conn.setAutoCommit(false);

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT NM_PROGRESSIVO FROM OPERGEST.PROGRESSIVI WHERE CD_PROGRESSIVO = 'PROVA' FOR UPDATE OF NM_PROGRESSIVO");
rs.next();
int progressivo = rs.getInt(1);

conn.commit();


La conclusione è che anche specificando la query a mano con il costrutto visual code SQLQuery non si riesce a prendere un lock esclusivo sul record, quindi la SELECT FOR UPDATE non funziona neanche in questa modalità. Facendo diversi tentativi sono giunto alla conclusione che l'unico modo per ottenere il risultato voluto utilizzando IDCachedRowSet è scrivere la query nel seguente modo (sempre riferendomi all'esempio DB2):

SELECT NM_PROGRESSIVO FROM OPERGEST.PROGRESSIVI WHERE CD_PROGRESSIVO = 'PROVA' WITH RR USE AND KEEP EXCLUSIVE LOCKS

[g.lanzi]

Grazie per la segnalazione e per l'analisi davvero esauriente.

Abbiamo inserito una richiesta di miglioramento per implementare questa feature.

Già che ci sei, non è che sai anche la sintassi per MySQL e Postgres? :P

[mtozzi]

e' semplice, dovrebbe essere: SELECT.... FOR UPDATE; in entrambi i casi :-)

[poidomani]

sì ci vorrebbe proprio così come ci vorrebbe la UPDATE ... FROM per poter aggiornare una serie di righe prelevando i dati da un'altra tabella

[g.lanzi]

Giovanni, ti chiedo un favore. Se vuoi proporre la UPDATE...FROM puoi inserire un altro thread nel forum?
Questo sulle SELECT FOR UPDATE è già stato accettato e non vorrei creare confusione.

grazie, a presto

[mtozzi]

Nei miglioramenti della versione 10 non ho visto l'implementazione della SELECT FOR UPDATE... l'avete scartata?

[lucabaldini]

No è solo che nella 10.0 abbiamo fatto alcune cose... per farle tutte ci vuole tempo...
E' nella lista delle cose da pensare/analizzare/valutare per il futuro...

[lucabaldini]

@mtozzi come ti dicevo era nella lista... ed ora è tra i miglioramenti della versione 10.1.

Trovi maggiori dettagli qui http://doc.progamma.com/?ARTID=312178BE-AB7B-4A84-82FE-7B55A0C03050