1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
-
- This file is part of the OpenLink Software Virtuoso Open-Source (VOS)
- project.
-
- Copyright (C) 1998-2018 OpenLink Software
-
- This project is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by the
- Free Software Foundation; only version 2 of the License, dated June 1991.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License along
- with this program; if not, write to the Free Software Foundation, Inc.,
- 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
-
-
-->
<sect1 id="inprocess"><title>Virtuoso In-Process Client</title>
<para>The in-process client is an efficient mechanism used by hosted applications
to access the database functionality of the hosting Virtuoso server.</para>
<para>Normally applications access Virtuoso using the remote procedure call mechanism
hidden behind some sort of higher-level API such as ADO.NET, ODBC, and so on.
The RPC based mechanism is the only available interface for non-hosted applications.
For hosted applications, when the application and the DBMS server reside in the same
OS process, Virtuoso provides a mechanism based on direct in-process procedure
calls.</para>
<para>The in-process call mechanism by itself is not exposed to the applications.
It is hidden behind the same APIs as the RPC one: ODBC, JDBC, ADO.NET. So in both
cases applications deal with the same APIs and the application logic does not
change. The application chooses which mechanism to use when it opens a
database connection.</para>
<para>To make an in-process connection to a Virtuoso server from within an
application hosted by the same server it is necessary to use a special inprocess address
syntax distinguishing it from the regular network "HOST:PORT" address syntax.
The In-process address has the following form:</para>
<programlisting>:in-process:PORT</programlisting>
<para>Note that it begins with a colon, then specifies the
"<computeroutput>in-process</computeroutput>" keyword, followed by another
colon, and finally the port number on which the server listens for TCP connections.</para>
<para>This port is only used for establishing the in-process connection, after which
the connection proceeds exclusively through the in-process procedure call mechanism.</para>
<para>The in-process connections are presently only supported by the Virtuoso
ODBC driver and the ODBC-based .NET Data Provider (OpenLink.Data.VirtuosoClient).
The managed .NET Data Provider (OpenLink.Data.Virtuoso) does not yet support
in-process connections.</para>
<para>In-process ODBC connection are defined in either a DSN or a connect string
directly. This is an example section of the odbc.ini file for unix/linux:</para>
<programlisting><![CDATA[
[InProcess]
Driver = /opt/virtuoso/lib/virtodbc32_r.so
Address = :in-process:1111
]]></programlisting>
<para>To open an ADO.NET connection the in-process address should be specified
in the connection string.</para>
<para>Here is an example of using the OpenLink.Data.VirtuosoClient adapter
specifying the details on the connect string:</para>
<programlisting><![CDATA[
VirtuosoConnection = new VirtuosoConnection ("HOST=:in-process:1111");
]]></programlisting>
<para>Every in-process connection originates from the existing connection.
For instance, it might be initiated by a stored procedure called from an
ISQL connection, or it can be called from an ASPX session.</para>
<para>In-process connections always inherit the user ID from its parent connection.
There is no way to set or change the connecting user ID. Therefore the user ID
and password are not specified when the in-process connection is opened.</para>
<para>In-process connections also limit database transactions. The autocommit mode
is never in effect for in-process connections. The setting of autocommit
mode is silently ignored without reporting any errors.</para>
</sect1>
|
