Newsgroup: it.comp.os.linux.development
Titolo: DB2

 <-
              -> LINUX: the choice of a GNU generation <-

parte di qualcuno che lo usa .
Su NT non e' un granche'
su Linux ho il cd ma non ho ancora avuto il tempo di provarlo.
IMHO e' roba vetusta che gira sui mainframe per applicazioni
belle grosse posso consigliarti Oracle o lo snello Postgresql
-- 
Saluti, Antonio Gallo
- Bad Penguin la distribuzione Linux italiana - 
http://www.badpenguin.org
- PRIME DI POSTARE QUI VAI SU 
http://www.badpenguin.org/info/dejanews.htm
- Non serve il Pentium 3 per andare in internet, basta non comprare un winmodem
- Se Linux non funziona e perche' non hai letto abbastanza manuali
- Tutta la doc e' su 
www.linuxdoc.org
, in italiano su 
www.pluto.linux.it
- Prima di cercare un programma vai su 
www.freshmeat.net
 o 
michel.enter.it

 
hai perfettamente ragione!


hai perfettamente ragione!
Pero' mi rendo conto che per chi sviluppa in Windows con Microfocus
o comunque in cobol e' un bel risparmio !!


belle grosse posso consigliarti Oracle o lo snello Postgresql
PostgreSQL purtroppo mi da' seri problemi per un caso di lock
concorrenti (infatti, va in deadlock). Ho dovuto risolvere in
maniera poco pulita, reimplementando il locking da me. Credo,
non ho fatto ancora prove, che MySQL da questo punto di vista
sia molto migliore (la politica di locking che adotta sembra,
se funziona ;-), deadlock-free).
Leonardo
".signature": bad command or file name

concorrenti (infatti, va in deadlock). Ho dovuto risolvere in
Ciao Leonardo!
Stai per caso usando qualche lock in una stored procedure ?
In che caso si verifica questo problema con PgSQL ?
Centrano transazioni e integrita' referenziale ??

In che caso si verifica questo problema con PgSQL ?
Ho una serie di transazioni; in ciascuna viene fatta una SELECT, poi una
UPDATE basata sul risultato della SELECT, e una INSERT in un'altra table
con i dettagli, diciamo:
	SELECT dati FROM worktable WHERE dati_accessibili;
	UPDATE worktable SET current_user = 'Io Me' WHERE primo_dato;
	INSERT INTO logfile (user, table, record, reason)
		VALUES('Io Me','worktable',RecNo,'Processing');
	...
	UPDATE worktable SET current_user = 'No One' WHERE primo_dato;
	INSERT INTO logfile (user, table, record, reason)
		VALUES('Io Me','worktable',RecNo,'Released');
"logfile" aggiorna automaticamente una timestamp e altra roba, ed ha una
entry sequenziale ( uniqueid int4 DEFAULT NEXTVAL('logid') ).
Se succede casino, l'intera transazione e' rolled back.
Problema: ogni tanto Dio Padre accede alla tabella logfile, per avere un
bel po' di informazioni statistiche su cosa e' successo nel frattempo, e
per farlo ci vuole un venti-trenta secondi.
Quanto basta perche' cinque o sei clients arrivino all'uno (o all'altro)
di quegli INSERT INTO e si fermino, giustamente.
Poi, pero', mi arriva una segnalazione di deadlock... "poi" significa da
2 a 10 minuti in cui i clients sono *fermi*. Brutto, molto.
MySQL ha una interessante ficiur ;-) di INSERT DELAYED (nonche' LIMIT in
SELECT) che mi sarebbe di grande aiuto.
Attualmente sto replicando il sistema su un altro server con MySQL. Poi,
quel server raccogliera' le operazioni degli altri clients e le riusera'
contro se stesso, simulando connessioni da diversi IP (in pratica ho una
foresta di ip_alias su quel server, dove 192.168.0.x e' il mio client, e
192.168.1.x e' l'alias di quel server su quel server :-) ).
E si stara' a vedere. Se funziona mi basta scaricare gli aliases, e fare
uno swap dei due servers (5 secondi con ifconfig <grin>).
Leonardo che ci sta studiando


 per farlo ci vuole un venti-trenta secondi.
Potresti copiare le righe della tabella che ti interessano in una TEMP
TABLE e poi elaborarle li' con comodo, quindi eliminare tale tabella, oppure
suddividere l'elaborazione in "sottoelaborazioni" che agiscano, di volta in
volta, solo su di un' insieme limitato dei dati della tabella.
-- 
Live free or die.  --  Debian/GNU/Linux die hard.

		VALUES('Io Me','worktable',RecNo,'Released');
Scusa ma prima e dopo hai messo dei lock o delle transazioni ?
Mi sembra strano che si blocchi su delle query cosi semplici.
-- 


Scusa ma prima e dopo hai messo dei lock o delle transazioni ?
Entrambi :-)
Se il cliente A e il cliente B fanno entrambi 
	SELECT dati FROM worktable WHERE dati_accessibili;
e' chiaro che NON DEVE ASSOLUTAMENTE SUCCEDERE che ricevano lo stesso
record. Quindi il primo dei due che becca il record deve marcarlo NON
ACCESSIBILE.
Col che non posso neanche usare una TEMP TABLE, perche' i clients "si
devono vedere" in tempo reale.
Avevo anche provato a fare:
	UPDATE worktable SET lockflag=1,lockowner=io WHERE dati_accessibili;
	(prende il primo)
	UPDATE worktable SET lockflag=0 WHERE lockowner=io AND oid!=got_rec;
	(continua a lavorare)
ma anche cosi' si bloccava (benche' non usassi piu' ne' LOCK ne' transazioni
dato che, a quel punto, non mi servivano), e ci metteva tempi cosmici, visto
che "dati_accessibili" puo' matchare anche 20mila records -- ora, fare 39999
updates in due colpi mi pare uno spreco.
Leonardo


updates in due colpi mi pare uno spreco.
mmm, probabilmente sono io che non ho capito
BTW hai mandato le query incriminate al team di Postgres ?

BTW hai mandato le query incriminate al team di Postgres ?
No: mi serviva una soluzione in tempi brevi :-)
