Newsgroup: it.comp.java
Titolo: parser XML thread SAFE

ciao a tutti,
	sono alle prese con un applicazione multi-thread. In pratica all'avvio 
istanzio n thread ognuno dei quali deve eseguire il parsing di documenti 
XML e salvare le info in un database. Il mio problema è che che il 
metodo parse() di Xerces risulta non essere thread-safe creandomi  seri 
problemi. Esiste un parser XML thread-safe? se no ... conoscete qualche 
work-around?
Personalmente ho ingenuamente provato a fare qualcosa tipo:
synchronized {
	... // some statement;
}
Ma ho ottenuto un secco rifiuto da parte del compilatore ;(
Ringrazio
-- 
Mess
http://www.mibmagazine.it

 creandomi  seri problemi.
Che tipo di problemi ?
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 
java.util.ConcurrentModificationException durante l'esecuzione multi-thread.
suggerimenti?
-- 
Mess
http://www.mibmagazine.it

 suggerimenti?
Tu fai partire n thread che leggono, immagino, n files separati. Hai 
delle strutture dati in comune ? Invece che cercare un parser 
thread-safe, perche' non eviti di far partire n thread ?


 
-- 
Mess
http://www.mibmagazine.it

 consiglio... ok?
OK, pero' non capisco perche' cerchi un parser XML sincronizzato invece 
che rinunciare ai thread.
Inoltre ci dev'essere qualcosa di sbagliato nel tuo codice se hai quel 
tipo di eccezione: I vari thread accedono in qualche modo ad una 
struttura dati comune ?


 dati comune ?
Certo, dao che si istanzia un solo builer per parserizzare i file...
Ho affrontato lo stesso problema...la mia soluzione č stata di creare un 
thread pool dinamico contenente istanze (ovviamente diverse) del builder, 
appena partiva una richiesta veniva richiesto al pool un builder che non si 
stava utilizzando, marchiandolo come occupato e liberando alla fine della 
"parserizzata".
Spero di esserti stato d'aiuto.
Ciao
Domenico 

 
mmmh se non sono troppo indiscreto puoi essere piu' preciso nel 
descrivere la tua soluzione. ;)
Il mio problema è che ho un sotto-sistema a cui accedo mediante un Proxy 
  che si occupa di prendere una URL, farne il parsing ed allocare gli 
oggetti necessari. Preciso che io non faccio altro che scrivere:
Proxy pn = new ProxyManager("
http://www.unaurl.com
");
Dal momento che questa operazione va fatta con cadenza regolare ma le 
URL dai parsare hanno dimensione variabile ho preferito istanziare un 
thread per ogni URL in modo da rendere asincrono il caricamento delle 
info nel DB. In codice java:
public class myClass extends Thread{
	public void run(){
	  try {
	    	new ProxyNews( url );
	  }
	  catch (InterruptedException ex) {
	  	log.debug("# ["
			+ this.getId()
			+ "] Puller thread interrupted ...");
	  }
	  catch (Exception ex) {
	  	System.err.println("# [" + this.getId()
			+ "] Puller Thread Exception ..."
			+ ex.getMessage() );
	    	ex.printStackTrace();
	  }
	  log.debug("# [" + this.getId() + "] Done!");
	}
}
Il problema è che nonostante il sotto-sistema non abbia nessuna variable 
static il metodo parse() dell'oggetto XMLReader di Xerces non è 
thread-safe creandomi il problema descritto nei post precedenti.
Ogni suggerimento è ben accetto.
-- 
Mess
http://www.mibmagazine.it


Suggerimento 1: ma perchè allora non ti scarichi in multithread i file e poi 
li parsifichi uno a uno? il tempo totale in questo caso non dovrebbe 
cambiare (se non hai un biprocessore o qualcosa di +)...
OK, se non sbaglio tu crei questi ProxyManager e all'interno usi il 
XMLReader che ti eri istanziato prima? se è cosi, il mio consiglio è quello 
di creare una pool di XMLReader e creare un metodo che ti ritorna un 
XMLReader libero che non sta parserizzando nessun file. (come un pool di 
connessioni al db....)
Saluti
Domenico 

 
-- 
Mess
http://www.mibmagazine.it

Signori,
	per dovere di cronaca vi riporto che non sono riuscito ad aggirare il 
problema ma ho dovuto rendere thread-safe il mio sotto-sistema di 
parsing serializzando l'accesso al parser XML mediante un Singleton.
Chi fosse interessato alla soluzione mi contatti senza problemi.
Ringrazio cmq tutti per l'aiuto e la voglia di collaborare.
-- 
Mess
http://www.mibmagazine.it
