SELECTs en transacciones COM+

20/12/2004 - 16:45 por prolog | Informe spam

A ver si alguien puede inclinar la balanza para algún lado.
Tengo un proyecto VB 6.0 de tres niveles (presentación, negocios,
datos), que trabaja en COM+ contra un SQL Server 2000.
En el nivel de negocios tengo montañas de métodos con código VB de
este tipo:

Public Function getPrecioConImpuesto(sData() As String, _
Rs As adodb.Recordset) As Boolean
On Error GoTo trap
Dim dt As CircDatos.DTArticulo
Dim oContext As ObjectContext

getPrecioConImpuesto = False

Set oContext = GetObjectContext()

If Not oContext Is Nothing Then
Set dt = oContext.CreateInstance(circDatos_DTArticulo)
Else
Set dt = CreateObject(circDatos_DTArticulo)
End If

getPrecioConImpuesto = dt.getPrecioConImpuesto(sData(), Rs)

If Not oContext Is Nothing Then oContext.SetComplete
Set oContext = Nothing
Set dt = Nothing

Exit Function

trap:
If Not oContext Is Nothing Then oContext.SetAbort
Set oContext = Nothing
Set dt = Nothing
LogErr clsName & "getPrecioConImpuesto"
End Function

Y en el nivel de datos tengo montañas de métodos con código VB de este
tipo:

Public Function GetPrecioConImpuesto(sData() As String, _
rs As ADODB.Recordset) As Boolean
On Error GoTo trap
Dim qry As String

GetPrecioConImpuesto = False

qry = "SELECT Precio = dbo.fn_Precio_con_Impuesto(" & sData(0) &
"," & Replace(sData(1), ",", ".") & ",'" & sData(2) & "') " & _
"FROM Articulo " & _
"WHERE iACpk_Art = " & sData(0)

GetPrecioConImpuesto = ConsultarRS(qry, rs)

Exit Function

trap:
LogErr clsName & "GetPrecioConImpuesto"
End Function

En otras palabras, tengo en la capa de negocios (Business Layer)
métodos que abren un contexto COM+ transaccional que invocan métodos
de la capa de datos (Data Translation) que sólo ejecutan SELECTS, es
decir, nada de updates, inserts y deletes. Por supuesto que además
tengo otros métodos que sí terminan en updates, inserts y deletes, o
combinaciones entre sí incluso mezcladas con selects, que también
-como corresponde- están transaccionales (es decir, GetObjectContext,
SetComplete o SetAbort según corresponda). En estos casos no hay
discusión posible: deben ser transaccionales sí o sí.

Ahora bien, se sospecha que cierta ineficiencia y bloqueos que se
producen en la base de datos (y causan errores) se deben a que estoy
usando transacciones COM+ que terminan ejecutando sólo SELECTs.

Mi pregunta es (o mis preguntas son): ¿ qué pasa si saco la
transaccionalidad para los métodos "SELECTS" ? ¿ gano en eficiencia o
termino rompiendo algo ?

Saludos.

Siga el debate

3 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#1 Tinoco

20/12/2004 - 17:09 | Informe spam

Hola Daniel,

Casi no entendi tus funciones, pero te recomiendo dos cosas:

1. No se debe utilizar ninguna clase de transaccion para realizar lecturas,
esto causa bloqueos de las tablas utilizadas, y es un bloqueo que no se
necesita. A menos que la lectura se haga en la misma transaccion de una
modificacion.

2. Es bueno utilizar Stored procedures en tus aplicaciones, esto puede
ayudar en eficiencia y cambios posteriores del aplicativo.

Hermilson Tinoco

"Daniel" wrote:

A ver si alguien puede inclinar la balanza para algún lado.
Tengo un proyecto VB 6.0 de tres niveles (presentación, negocios,
datos), que trabaja en COM+ contra un SQL Server 2000.
En el nivel de negocios tengo montañas de métodos con código VB de
este tipo:

Public Function getPrecioConImpuesto(sData() As String, _
Rs As adodb.Recordset) As Boolean
On Error GoTo trap
Dim dt As CircDatos.DTArticulo
Dim oContext As ObjectContext

getPrecioConImpuesto = False

Set oContext = GetObjectContext()

If Not oContext Is Nothing Then
Set dt = oContext.CreateInstance(circDatos_DTArticulo)
Else
Set dt = CreateObject(circDatos_DTArticulo)
End If

getPrecioConImpuesto = dt.getPrecioConImpuesto(sData(), Rs)

If Not oContext Is Nothing Then oContext.SetComplete
Set oContext = Nothing
Set dt = Nothing

Exit Function

trap:
If Not oContext Is Nothing Then oContext.SetAbort
Set oContext = Nothing
Set dt = Nothing
LogErr clsName & "getPrecioConImpuesto"
End Function

Y en el nivel de datos tengo montañas de métodos con código VB de este
tipo:

Public Function GetPrecioConImpuesto(sData() As String, _
rs As ADODB.Recordset) As Boolean
On Error GoTo trap
Dim qry As String

GetPrecioConImpuesto = False

qry = "SELECT Precio = dbo.fn_Precio_con_Impuesto(" & sData(0) &
"," & Replace(sData(1), ",", ".") & ",'" & sData(2) & "') " & _
"FROM Articulo " & _
"WHERE iACpk_Art = " & sData(0)

GetPrecioConImpuesto = ConsultarRS(qry, rs)

Exit Function

trap:
LogErr clsName & "GetPrecioConImpuesto"
End Function

En otras palabras, tengo en la capa de negocios (Business Layer)
métodos que abren un contexto COM+ transaccional que invocan métodos
de la capa de datos (Data Translation) que sólo ejecutan SELECTS, es
decir, nada de updates, inserts y deletes. Por supuesto que además
tengo otros métodos que sí terminan en updates, inserts y deletes, o
combinaciones entre sí incluso mezcladas con selects, que también
-como corresponde- están transaccionales (es decir, GetObjectContext,
SetComplete o SetAbort según corresponda). En estos casos no hay
discusión posible: deben ser transaccionales sí o sí.

Ahora bien, se sospecha que cierta ineficiencia y bloqueos que se
producen en la base de datos (y causan errores) se deben a que estoy
usando transacciones COM+ que terminan ejecutando sólo SELECTs.

Mi pregunta es (o mis preguntas son): ¿ qué pasa si saco la
transaccionalidad para los métodos "SELECTS" ? ¿ gano en eficiencia o
termino rompiendo algo ?

Saludos.

Responder a este mensaje

#2 Maxi

20/12/2004 - 17:20 | Informe spam

Hola, los Select generan bloqueos a menos que indiques lo contrario en la
misma instruccion Select.

Ahora, generar transacciones para Select? yo la verdad que nunca vi algo
igual :(, las transacciones yo las uso solo para asegurar integridad de la
entidad

Salu2
Maxi

"Daniel" escribió en el mensaje
news:

A ver si alguien puede inclinar la balanza para algún lado.
Tengo un proyecto VB 6.0 de tres niveles (presentación, negocios,
datos), que trabaja en COM+ contra un SQL Server 2000.
En el nivel de negocios tengo montañas de métodos con código VB de
este tipo:

Public Function getPrecioConImpuesto(sData() As String, _
Rs As adodb.Recordset) As Boolean
On Error GoTo trap
Dim dt As CircDatos.DTArticulo
Dim oContext As ObjectContext

getPrecioConImpuesto = False

Set oContext = GetObjectContext()

If Not oContext Is Nothing Then
Set dt = oContext.CreateInstance(circDatos_DTArticulo)
Else
Set dt = CreateObject(circDatos_DTArticulo)
End If

getPrecioConImpuesto = dt.getPrecioConImpuesto(sData(), Rs)

If Not oContext Is Nothing Then oContext.SetComplete
Set oContext = Nothing
Set dt = Nothing

Exit Function

trap:
If Not oContext Is Nothing Then oContext.SetAbort
Set oContext = Nothing
Set dt = Nothing
LogErr clsName & "getPrecioConImpuesto"
End Function

Y en el nivel de datos tengo montañas de métodos con código VB de este
tipo:

Public Function GetPrecioConImpuesto(sData() As String, _
rs As ADODB.Recordset) As Boolean
On Error GoTo trap
Dim qry As String

GetPrecioConImpuesto = False

qry = "SELECT Precio = dbo.fn_Precio_con_Impuesto(" & sData(0) &
"," & Replace(sData(1), ",", ".") & ",'" & sData(2) & "') " & _
"FROM Articulo " & _
"WHERE iACpk_Art = " & sData(0)

GetPrecioConImpuesto = ConsultarRS(qry, rs)

Exit Function

trap:
LogErr clsName & "GetPrecioConImpuesto"
End Function

En otras palabras, tengo en la capa de negocios (Business Layer)
métodos que abren un contexto COM+ transaccional que invocan métodos
de la capa de datos (Data Translation) que sólo ejecutan SELECTS, es
decir, nada de updates, inserts y deletes. Por supuesto que además
tengo otros métodos que sí terminan en updates, inserts y deletes, o
combinaciones entre sí incluso mezcladas con selects, que también
-como corresponde- están transaccionales (es decir, GetObjectContext,
SetComplete o SetAbort según corresponda). En estos casos no hay
discusión posible: deben ser transaccionales sí o sí.

Ahora bien, se sospecha que cierta ineficiencia y bloqueos que se
producen en la base de datos (y causan errores) se deben a que estoy
usando transacciones COM+ que terminan ejecutando sólo SELECTs.

Mi pregunta es (o mis preguntas son): ¿ qué pasa si saco la
transaccionalidad para los métodos "SELECTS" ? ¿ gano en eficiencia o
termino rompiendo algo ?

Saludos.

Responder a este mensaje

#3 José Miguel Torres

21/12/2004 - 10:30 | Informe spam

Hola Daniel.

COM+ no implica SÓLO transacciones. Es decir, COM+ es una serie de servicios
que posibilitan una mayor escalabilidad de tu apliación entre ellas las
transacciones. Comparto la opinión de Daniel y Tinoco, transacciones en
selects es absurdo pero te diré más, no utilizes transacciones. Entonces
para que utilizar COM+??? te preguntarás. mira los servicios Object Pool,
Just-In-Time e incluso CRM, entre otros, estos son la razón de COM+. Las
transacciones son utilizadas de manera inequívoca el 95% de las veces. SóLO
y digo SÓLO deberíamos utilizar transacciones si, el número de origenes de
datos con el que trabajamos es mayor de 1, y si el componente utiliza
recursos del sistema críticos. Así, la expresión que hacias referencia <<
utilizar transacciones en update, insert es sí o sí>> cambiala por no o
no, acertarás y la escalabilidad de la aplicación te lo agradecerá.

PD: Utiliza transacciones si quieres desde los procedimientos almacenados
que es donde deberian estar las intrucciones insert, delete update. Estas
transacciones consumirán menos puesto que serán locales.

saludos

José Miguel Torres
jtorres_diaz~~ARROBA~~terra.es
http://jmtorres.blogspot.com

"Daniel" escribió en el mensaje
news:

A ver si alguien puede inclinar la balanza para algún lado.
Tengo un proyecto VB 6.0 de tres niveles (presentación, negocios,
datos), que trabaja en COM+ contra un SQL Server 2000.
En el nivel de negocios tengo montañas de métodos con código VB de
este tipo:

Public Function getPrecioConImpuesto(sData() As String, _
Rs As adodb.Recordset) As Boolean
On Error GoTo trap
Dim dt As CircDatos.DTArticulo
Dim oContext As ObjectContext

getPrecioConImpuesto = False

Set oContext = GetObjectContext()

If Not oContext Is Nothing Then
Set dt = oContext.CreateInstance(circDatos_DTArticulo)
Else
Set dt = CreateObject(circDatos_DTArticulo)
End If

getPrecioConImpuesto = dt.getPrecioConImpuesto(sData(), Rs)

If Not oContext Is Nothing Then oContext.SetComplete
Set oContext = Nothing
Set dt = Nothing

Exit Function

trap:
If Not oContext Is Nothing Then oContext.SetAbort
Set oContext = Nothing
Set dt = Nothing
LogErr clsName & "getPrecioConImpuesto"
End Function

Y en el nivel de datos tengo montañas de métodos con código VB de este
tipo:

Public Function GetPrecioConImpuesto(sData() As String, _
rs As ADODB.Recordset) As Boolean
On Error GoTo trap
Dim qry As String

GetPrecioConImpuesto = False

qry = "SELECT Precio = dbo.fn_Precio_con_Impuesto(" & sData(0) &
"," & Replace(sData(1), ",", ".") & ",'" & sData(2) & "') " & _
"FROM Articulo " & _
"WHERE iACpk_Art = " & sData(0)

GetPrecioConImpuesto = ConsultarRS(qry, rs)

Exit Function

trap:
LogErr clsName & "GetPrecioConImpuesto"
End Function

En otras palabras, tengo en la capa de negocios (Business Layer)
métodos que abren un contexto COM+ transaccional que invocan métodos
de la capa de datos (Data Translation) que sólo ejecutan SELECTS, es
decir, nada de updates, inserts y deletes. Por supuesto que además
tengo otros métodos que sí terminan en updates, inserts y deletes, o
combinaciones entre sí incluso mezcladas con selects, que también
-como corresponde- están transaccionales (es decir, GetObjectContext,
SetComplete o SetAbort según corresponda). En estos casos no hay
discusión posible: deben ser transaccionales sí o sí.

Ahora bien, se sospecha que cierta ineficiencia y bloqueos que se
producen en la base de datos (y causan errores) se deben a que estoy
usando transacciones COM+ que terminan ejecutando sólo SELECTs.

Mi pregunta es (o mis preguntas son): ¿ qué pasa si saco la
transaccionalidad para los métodos "SELECTS" ? ¿ gano en eficiencia o
termino rompiendo algo ?

Saludos.

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

Busqueda sugerida