[SQL Server 2005] Procedure in esecuzione

martedì 30 novembre 2010 - 09.26

GruppoETD Profilo | Newbie

Ciao a tutti,
è possibile conoscere tramite codice t-sql se una procedura (anche se stessa) è in esecuzione in modo che nessuno possa eseguirla se è già in esecuzione.

Mi servirebbe una specie di lock che blocchi l'esecuzione della procedura quando è già stata chiamata (ed è attiva) fino alla sua completa esecuzione.

Grazie.

alx_81 Profilo | Guru

>Ciao a tutti,
Ciao

>è possibile conoscere tramite codice t-sql se una procedura (anche
>se stessa) è in esecuzione in modo che nessuno possa eseguirla
>se è già in esecuzione.
>Mi servirebbe una specie di lock che blocchi l'esecuzione della
>procedura quando è già stata chiamata (ed è attiva) fino alla
>sua completa esecuzione.
per la procedura non mi viene nulla, però mi sembra che vuoi fare un lock seriale.
Personalmente, con la dovuta attenzione, serializzerei una transazione nella stored procedure, in modo che chiunque la richiami dopo qualcun altro si ritrova ad aspettare la fine dell'esecuzione precedente.
Per maggiori info leggi qui:
http://msdn.microsoft.com/it-it/library/ms173763.aspx alla voce SERIALIZABLE

>Grazie.
di nulla!
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

GruppoETD Profilo | Newbie

Ciao ho letto le specifiche del comando che riguardano la modifica dei dati, io purtroppo ho una procedura diversa che chiama un assembli (senza restrizioni) che comunica con un altro programma di windows del tipo

alter procedure usp_CallAssembly()
begin
declare @var as int

set @var = ufn_ExternalAssembly()

if @var <> 0
begin
exec writetolog 'error'
end
end


il serializable é valido anche per le chiamate assembly?

Grazie :-)

alx_81 Profilo | Guru

>Ciao ho letto le specifiche del comando che riguardano la modifica
>dei dati, io purtroppo ho una procedura diversa che chiama un
>assembli (senza restrizioni) che comunica con un altro programma
>di windows del tipo
>
>alter procedure usp_CallAssembly()
>begin
> declare @var as int
>
> set @var = ufn_ExternalAssembly()
>
> if @var <> 0
> begin
> exec writetolog 'error'
> end
>end
>
>
>il serializable é valido anche per le chiamate assembly?
puoi farlo da codice direttamente con la SQLTransaction (http://msdn.microsoft.com/it-it/library/system.data.sqlclient.sqltransaction(VS.80).aspx, http://msdn.microsoft.com/it-it/library/system.data.sqlclient.sqltransaction_members(v=VS.80).aspx)

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

GruppoETD Profilo | Newbie

ciao il fatto è che il codice dell'assembly non è di tipo sql è un redirect ad una dll.
ma credo che a me serve una condizione da verificare prima della chiamata dell'assembly.

per spiegarmi meglio:
supponiamo una procedure di questo tipo

alter procedure notepad()
begin
exec xp_cmdshell 'notepad' ;
end

Sul server di cui mi occupo (che è in Produzione) se arrivano due chiamate a questa procedura molto ravvicinate (tipo qualche millisecondo -> Accertato) sql server va in crash e mi genera un errore per cui non accetta più connessioni!! fino al riavvio di sql server (certe volte devo riavviare l'intero server)


Riflessione:
Avevo anche creato anche una tabella(1x1) per memorizzare chi stava lanciando la procedura.. ma se le chiamate sono molto vicine la seconda chiamata non vede l'update della prima. forse è lì che devo usare la serializzazione?
Ma con la serializzazione la seconda chiamata della procedura rimane in attesa? come si comporta in caso di lettura di una tabella in lock dalla prima chiamata?

Grazie.

alx_81 Profilo | Guru

>alter procedure notepad()
>begin
> exec xp_cmdshell 'notepad' ;
>end
chi chiama la sp? perchè se la chiami da un'altra dll, puoi fare lock sul chiamante con il lock del processo..

>Riflessione:
>Avevo anche creato anche una tabella(1x1) per memorizzare chi
>stava lanciando la procedura.. ma se le chiamate sono molto vicine
>la seconda chiamata non vede l'update della prima. forse è lì
>che devo usare la serializzazione?
sì, lì ti conviene, perchè se due arrivano insieme rischi di rompere il giochino..

>Ma con la serializzazione la seconda chiamata della procedura
>rimane in attesa? come si comporta in caso di lettura di una
>tabella in lock dalla prima chiamata?
seriale, uno per uno, e il secondo resta in attesa..

>Grazie.
di nulla!
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

GruppoETD Profilo | Newbie

Perfetto allora ricapitolando:
-> TABELLA MyLock una colonna isLock di tipo tinyint

-> PROCEDURE:
declare @LockStatus as tinyint
set @LockStatus = 1 -- la fisso già nel peggiore dei casi

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
begin transaction
select top 1 @LockStatus = isLock from MyLock

if @LockStatus = 0
begin
update MyLock set isLock = 1
call external trigger
update MyLock set isLock = 0
end
commit


Domanda:
Se le due chimate sono ravvicinatissime, diciamo 1 millisecondo. funziona lo stesso questo sistema?

alx_81 Profilo | Guru

>Domanda:
>Se le due chimate sono ravvicinatissime, diciamo 1 millisecondo.
>funziona lo stesso questo sistema?
tutto quello che è sotto transazione è serializzato, quindi tutto il blocco viene eseguito in maniera esclusiva.
Ma perchè non serializzi direttamente la chiamata alla sp senza passare da una tabella?
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi

GruppoETD Profilo | Newbie

perchè la chiamata può arrivare da diverse procedure.. bisogna per forza serializzare la chiamata all'assembly

Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5