Il problema di fondo era che la chiamata JNI_CreateJavaVM produceva il segnale SIGABRT quando invocato all’interno di un altro framework, nello specifico stavo utilizzando l’SDK BoKS.

La porzione di codice interessata, a parte dovuti accorgimenti, era del tutto coerente con quanto riportato da HP al link

http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html

Provando ad utilizzare i parametri di inizializzazione della VM più svariati non si è cavato un ragno dal buco, seguendo comunque le linee guida riportate qui http://www.docs.hp.com/en/JAVAPROGUIDE/JNI_java2.html#primordial, si è ipotizzato da subito un problema con lo stacksize su HP-UX, su Solaris, infatti, non erano stati riscontrati problemi di sorta.

Una sessione con tusc ha confermato quanto supposto:

La soluzione?

Un semplice export della variabile PTHREAD_DEFAULT_STACK_SIZE a 524288.

Si sarebbe anche potuta usare la chiamata pthread_default_stacksize_np(), ma poiché la parte di codice che crea i thread non è personalizzabile in quel dato SDK, l’export della variabile d’ambiente è stata l’unica soluzione attuabile.

Alla prossima!

Con questo tipo di accesso però, avevo notato perdite di dati sul database, non tutto infatti diventava persistente e, certo di non aver scritto codice errato, iniziavo a pensare di non capirci più nulla.

Il fatto è che, a differenza di quanto ero solito fare con altri RDBMS, non è sufficiente chiudere una connessione con

al termine dell’esecuzione del programma, il driver effettua caching delle tabelle per ottimizzare gli accessi al file system e non tutte le modifiche vengono scritte sul file.

È necessario fornire al driver l’istruzione di “SHUTDOWN” di modo che tutti i dati eventualmente ancora in cache vengano correttamente resi persistenti:

Esiste inoltre, una funzione di shutdown che effettua anche una riorganizzazione del database ed una compressione dei dati. Essendo un’operazione lenta è bene non usarla troppo di frequente, il criterio d’uso è lo stesso di “SHUTDOWN”, “SHUTDOWN COMPACT”.

Alla prossima :)

Il codice in questione sembra, infatti, causare un piccolo problema chiamato deadlock.

La cosa non si presenta sempre, ma dipende fortemente dalla quantità di output che genera il comando e da come il sistema operativo gestisce il buffering della system call “write”. Lanciando truss da dentro al codice java, infatti, notavo che l’esecuzione delle system call si bloccava in attesa:

Non è stato facilissimo arrivare alla causa, il metodo è infatti molto semplice, ma adesso che ho identificato il problema l’errore appare quasi evidente. Il problema risiede infatti nel canale di standard error letto prima dello standard output:

1. Prima di poter leggere lo standard error è necessario che il processo che esegue il comando termini, e non è detto che vi siano errori;
2. Prima di poter avere tutto l’output disponibile c’è bisogno di qualcuno che consumi i dati nel buffer, ma quel qualcuno è in attesa sullo standard error;
3. Deadlock!

Sinceramente, questa spiegazione, seppur sensata non mi convince ancora appieno e appena avrò più tempo analizzerò meglio i trace delle system call, nonostante ciò riporto di seguito la versione del metodo che risolve il problema.

Process proc = Runtime.getRuntime().exec(cmd);

/*consume the output*/
stdout = new BufferedReader(new InputStreamReader(
proc.getInputStream()));
temp = stdout.readLine();

while(temp!=null){
if(result==null)
result = temp+”\n”;
else
result += temp+”\n”;
temp = stdout.readLine();
}

stdout.close();

/*check if errors occurred*/
stderr = new BufferedReader(new InputStreamReader(
proc.getErrorStream()));
temp = stderr.readLine();

if(temp!=null){
result = temp+”\n”;
temp = stderr.readLine();
while(temp!=null){
result += temp+”\n”;
temp = stderr.readLine();
}

stderr.close();
throw new IOException(result);
}

stderr.close();
/*if no exceptions occurred then proceed to return the output*/
return result;
}

Questo è quanto, il metodo main d’esempio del post precedente però è ancora valido :)

In realtà i due costrutti sono molto più diversi di quanto non si creda. Ogni comando SQL ricevuto dal DBMS viene elaborato seguendo 3 fasi:

1. Compilazione (parsing del comando SQL);
2. Esecuzione;
3. Fetching (restituzione del risultato al client).

Supponendo che vengano eseguite molte operazioni, la classe PreparedStatement permette di eseguire il passo di compilazione una sola volta, la prima, e poi di aggiornarne i valori in seguito:

Questo si concretizza in un miglioramento delle performance, generalmente. Ciò non è sempre vero, ci sono altri fattori che entrano in gioco che possono rendere uno Statement più veloce di un PreparedStatement. A mio avviso anche se fosse, una leggera diminuzione di performance (che dipende moltissimo dal database utilizzato) per il PreparedStatement è sicuramente ben accetta data la sua grande flessibilità. Non solo, dalle FAQ Oracle ho appreso anche che ci sono dei benefici in termini di sicurezza nell’utilizzo di PreparedStatement: il binding dei dati, infatti, eviterebbe un considerevole numero di attacchi di tipo SQL Injection. La FAQ infatti riporta:

“Statements may be slightly faster if you are only going to execute the SQL once. PreparedStatements are much faster when the SQL will be executed more than once. If you are using the statement cache, which you should, getting a statement from the cache is the same as executing the same statement.

In general we strongly recommend that you use PreparedStatements. This is especially true if you are sending user provided data in the SQL. By binding the data to a PreparedStatement parameter you can prevent most SQL injection attacks. Any performance advantage of using Statements is negligible.”

Insomma, per i miei gusti, non c’è motivo di usare Statement e PreparedStatement è la classe vincente.

L’idea è semplice: se il comando fallisce, restituisco l’esito del comando (lo standard error) come un’eccezione di I/O, altrimenti il metodo torna l’esito del comando (lo standard output).

A questo punto possiamo, per esempio, scrivere il seguente main, un po’ inutile, ma rende l’idea

Ovviamente il codice non è ottimizzato essendo la prima stesura di getto, alcune cose potevano essere evitate (i due BufferedReader per esempio), ma spero che a qualcuno questo metodo torni utile.

La versione 10g di Oracle, però, supporta l’operazione “MERGE”, entrata a far parte dello standard SQL nel 2003, e si è rivelata molto comoda utilizzandola tramite JDBC.

Supponiamo di dover memorizzare in una tabella l’ultima pagina visitata da un utente in un dato giorno, possiamo utilizzare il seguente prepared statement java:

In sostanza, l’operazione “MERGE” funziona tra tabelle, prende i valori di una e li inserisce o aggiorna nell’altra in base al matching della condizione nella clausola “ON”.
Tuttavia, la necessità non era di utilizzare valori preesistenti di una tabella ed inserirli o aggiornarli nell’altra, ma l’effettivo popolamento della tabella. Esigenza risolta appoggiandosi alla tabella “DUAL”.
Ovviamente, invece di inserire direttamente nella stringa i valori necessari, si poteva utilizzare anche il ‘?’ e chiamare poi le funzioni della classe PreparedStatement.

Se non vi sono particolari necessità in termini di performance, sicurezza, flessibilità, in genere preferisco inserire tutto direttamente nella stringa in modo da poterla scrivere facilmente su un file di log prima di inviarla al driver: