"Herby" <prmarjoram@gmail.com> wrote in message
news:1159866239.972024.31310@k70g2000cwa.googlegroups.com...
Egbert Nierop (MVP for IIS) wrote:
"Herby" <prmarjoram@gmail.com> wrote in message
news:1159787801.059081.89760@m73g2000cwd.googlegroups.com...
We have a client and server application that run on the same
machine.
We want both to participate in the same transaction.
To acheive this I understand they need to share the same connection
object.
The server currently supports a COM interface, as the client passes
across copies of simple data types Strings and integers etc.
But now they want to pass across the client ADO connection object.
The
data-writes within the server should then use this connection object
for creating its recordsets etc.
On return to the client - the client may then decide to commit or
rollback via the same connection object.
I understand the server would have a proxy back to the actual
connection object residing in the client address space. Is this
going
to work?
No offense intended but this is impossible. A connection, is in fact a
TCP/IP connection (for instance) to a SQL database server.
As you might guess, a single process can host one or more TCP/IP
connections, but one connection belongs _exactly_ to one
process.
As soon as you 'share' the connection, you are fooling yourself to
think
that you have just one connection. You will have two connection in
addition,
there -will- be a lot of marshalling at the runtime of COM.
It's much more performance and security wise, to -not- share
connection
objects. Just rely on the perfect resource pooling features of
Windows.
Could you explain "Just rely on the perfect resource pooling features
of Windows?"
Illustrate.
Create one or more COM objects that all use the same connection string.
Now open and close the connection (from the connection string) -per
method-
within these COM objects.
Create (instanciate) those COM objects within a process.
Notice that even if you have called different methods from different COM
components that each opened and closed there respective ADODB.Connection
object, at the SQL server side you only see one connection being
utilized.
You get that feature for free. This is called: "resource pooling". (and
ODBC
used connection pooling).
With all respect to your managers, but they probably are thinking in
mainframe times or in times where the client-server connections were too
expensive so programmers in ancient times had to 'share' connections
manually.
My managers think they can just pass across an ADO connection object
from 1 process
to the other - I need to justify this is impossible?
This is impossible. You cannot share -one TCP-IP connection (or named
pipes)
between 2 or more processes. You can 'share' a ADODB.connection object
but
this is fooling the managers. In effect, there will be 2 connections
while
your runtime has become sloppy and slower.
Thanks for your help.
Im sure you are all right. They still want me to produce a example
that proves it.