Newsgroup: it.comp.lang.delphi
Titolo: D7E + Ado + Oracle - Stored Procedure in ambiente multithread

Un saluto a tutti.
La domanda è tosta e anticipo che ricerche su google hanno dato scarso
esito.
Ho un servizio win32 che usa un database Oracle 10g tramite ado.
Nel servizio ho un po di threads che *condividono* la connessione al
database, cioè, ho una sola tadoconnection per tutti i threads.
Ora, tutti questi threads hanno in comune la necessita di chiamare una
stored procedure che ha dei parametri, circa 20...
Avevo progettato le cose in modo che ogni singolo thread usasse una
tadostoredproc propria e quando necessario usava questo oggetto
proprio e assolutamente non condiviso per chiamare la stored procedure
su oracle.
Ho scoperto che questa cosa manda tutto in crash...
Modificando il codice, ovvero usando UNA SOLA istanza di
tadostoredproc alla quale accedono tutti i threads e subordinando
l'accesso a questa unica istanza con una critical section, tutto
funziona senza problemi.
Ho provato a cercare su forum specifici di oracle ma non ho trovato
niente di rilevante.
Mo mi resta il dubbio..
Quale dei 2 non permette di usare nella *stessa* sessione la *stessa*
stored procedure, ado oppure papa' Oracle?
Attenzione, non parlo dell'istanza  di tadostoredproc: parlo proprio
della stored procedure come "oggetto persistente sul database"....
Non mi costa tanto lasciare le cosi come sono adesso, con la critical
section...
Ma sarei proprio curioso di capire se è ado che fa casino oppure SE LE
CHIAMARE ALLE PROCEDURE SU ORACLE NON SONO THREAD SAFE....
Pax vobiscum
A.

 CHIAMARE ALLE PROCEDURE SU ORACLE NON SONO THREAD SAFE....
Non � che invece usando una critical section dai molti threads fai in 
modo che il singolo oggetto stored proc acceda alla tadoconnection ma 
sempre nel main thread ? Mi viene il dubbio, invece, che sia proprio la 
connessione al db a soffrire dei multiaccessi dai thread dei singoli 
TAdoStoredProc usati nei threads stessi.
Per capire la cosa, potresti provare anche ad avere una connessione al 
db per ogni singolo thread e vedere se l'applicazione va ancora in 
crash, cosa di cui dubito. Ma a questo punto dovresti poter riuscire a 
trovare una sorta di soluzione, magari con un pool di connessioni 
ottimizzate.
Antonio

 ottimizzate.
l'idea di usare piu' connessione per un test va bene, ma...
1) se tutto va, continuerei a non sapere per "colpa" di chi....
2) se non va, presumibilmente vorrebbe dire che oracle non supporta
questa particolare operazione, ovvero che le chiamate alle procedure
non sono thread safe...
L'incazzatura è che non posso fare prove con dbx....
Il c@@@o di driver per oracle fornito con d7 ha un bug prp per le
stored procedure...
Il bastardo duplica n volte i parametri, dove n è il numero di utenti
o schema definiti sul database...
Se non ci fosse questa cosa, avrei certo usato dbx e mollato ado..
Ma visto che qua tutto si basa su ado non posso andare a chiedere
soldi per compare il driver corelab... :-(((
Anto', grazie... mi hai dato un diverso punto di vista! :-D
A.

 su oracle.
ADO � threadsafe (� basato su COM), il wrapper VCL della versione 7 no (da 
quel che so io).
Puoi mostrare un poco di codice, soprattutto come crei la SP nel thread?
Ciao
ACSH
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Puoi mostrare un poco di codice, soprattutto come crei la SP nel thread?
non c'è molto.
Il thread per l'accesso ai dati usa un oggetto costruito da me che fa
da wrapper.
Questa classe ha una property che indica se serve una query o una
stored procedure.
In funzione di tale property, al primo utilizzo creo l'oggetto che mi
serve con un semplice TAdoQuery.Create(Nil) e TAdoStoredProc.Create
(Nil).
appioppo la connection leggo i parametri e via...Niente di che.
Ovviamente, se cambio il valore della property e dico che mi serve una
query, distruggo la tadostoredproc e creo una tadoquery...
...vuoi vedere che non è ne colpa di ado ne di oracle ma di delphi?
Questo potrebbe essere il motivo x cui non ho trovato un "pene"...
Tnx!
A.

 Questo potrebbe essere il motivo x cui non ho trovato un "pene"...
Quello che dice ACSH ha fondamento, nel senso che comunque viene tutto 
incapsulato in TComponent e a quel punto il problema potrebbe proprio 
essere quello, visto che la VCL non � thread safe e potrebbe darti dei 
problemi. Non conosco ADO ma una soluzione potrebbe essere quella di 
spulciare codice da qualche parte per istanziarti l'oggetto senza far 
uso del component delphi, e vedere se hai ancora problemi con la 
connessione.
Antonio

 funziona senza problemi.
Alb�, magari questo ti � sfuggito su usenet:

guastatore ha scritto:

eemmmh :)
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.database.ado/2004-01/0070.html
Antonio

 
http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.data.
..
ehm....Io ho cercato x oracle e quel th parla di sqlserver
cioè, se ho un servizio che apre n thread du un db devo avere n
connessioni? .. non so...
Appena ho 2 secondi faccio qlc prova e posto l'esito qua magari su un
th apposito...
Grazie per tutte le risposte, gente! :-D
A.

 appioppo la connection leggo i parametri e via...Niente di che.
Secondo me, OGNI thread ha la neccessit� che venga inizializzato COM,
quindi devi fare qualcosa del genere nell'execute del thread (pseudocodice):
begin
 CoInitialize(nil);
 Query := TAdoquery.Create(nil);
 try
  Query.ConnectionString := StringaDiConnessione;
  // resto della fuffa
 finally
  Query.Free;
 end;
 CoUninitialize() ;
end;
Ciao
-- 
ACSH
[TurboDelphi]
Chi fa da se', fatica il doppio

>  CoInitialize(nil);
ehm....se non fai questa in ogni thread col c@@@o che ado funziona....
Solo che, come nella migliore (tse') tradizione di zio billy, se non
chiami questa cosa e tenti di usare ado mica ti esce un dito medio con
la frase "stru...z, se non chiami coinitialize col c@@@o che ti faccio
funzionare ado..." ma un messaggio del tipo "tipo di dati non
supportato".
Ovviamente, tu lo leggi e capisci subito che non hai chiamato
coinitialize....
Poi mi prendevate per il didietro quando sparavo ad alzo zero con la
storia del TIS: Telepatic Information Server.... lol!
Sulle query il casino sembra non esserci... Il problema io l'ho
beccato usando le stored procedure.
A.

non vorrei fare il olito polemico.......ma sarebbe meglio non usare gli 
ado con oracle.....

 ado con oracle.....
e cos'altro?
A.



o usi dbexpress(velocissimo e stabilisimo) o provi i DAO (mi sembra siano 
a pagamento) specifici per oracle.
ciao

 a pagamento) specifici per oracle.
Si chiamano DOA (Direct Oracle Access).
Ma l'azienda al momento non ha intenzione di fare questo investimento
ne quello per il driver dbx della corelab specifico per oracle.
Ergo: mi tocca ado.
Pax vobiscum.
A.