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.
 

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.

Preguntas similares