Database Connectivity:: Computer Science Client Database Server Commands Data-Centric Connection Pooling

Database Connectivity:
A database connection is a facility in computer science that allows

client software to communicate with database server software, whether
on the same machine or not. A connection is required to send commands
and receive answers.
Connections are a key concept in data-centric programming. Since some

DBMS engines require considerable time to connect connection pooling
was invented to improve performance. No command can be performed
against a database without an "open and available" connection to it.
Connections are built by supplying an underlying driver or provider with

a connection string, which is a way of addressing a specific database or
server and instance as well as user authentication credentials (for
example, Server=sql_box(your ip
address);Database=Common;User ID=uid(sa-by
default);Pwd=password;). Once a connection has been built it can
be opened and closed at will, and properties (such as the command time-
out length, or transaction, if one exists) can be set. The Connection
String is composed of a set of key/value pairs as dictated by the data
access interface and data provider being used.
Databases, such as PostgreSQL, only allow one operation to be

performed at a time on each connection. If a request for data (a SQL
Select statement) is sent to the database and a result set is returned, the
connection is open but not available for other operations until the client
finishes consuming the result set. Other databases, like SQL Server 2005
(and later), do not impose this limitation. However, databases that
provide multiple operations per connection usually incur far more
overhead than those that permit only a single operation task at a time.
Pooling
Database connections are finite and expensive and can take a

disproportionately long time to create relative to the operations
performed on them. It is very inefficient for an application to create and
close a database connection whenever it needs to update a database.
Connection pooling is a technique designed to alleviate(improve) this

problem. A pool of database connections can be created and then shared
among the applications that need to access the database. When an
application needs database access, it requests a connection from the
pool. When it is finished, it returns the connection to the pool, where it
becomes available for use by other applications.
The connection object obtained from the connection pool is often a

wrapper around the actual database connection. The wrapper
understands its relationship with the pool, and hides the details of the
pool from the application. For example, the wrapper object can
implement a "close" method that can be called just like the "close"
method on the database connection. Unlike the method on the database
connection, the method on the wrapper may not actually close the
database connection, but instead return it to the pool. The application
need not be aware of the connection pooling when it calls the methods
on the wrapper object.
This approach encourages the practice of opening a connection in an

application only when needed, and closing it as soon as the work is
done, rather than holding a connection open for the entire life of the
application. In this manner, a relatively small number of connections can
service a large number of requests. This is also called multiplexing.
In client/server architecture, on the other hand, a persistent connection is

typically used so that server state can be managed. This "state" includes
server-side cursors, temporary products, connection-specific functional
settings, and so on.
It is desirable to set some limit on the number of connections in the pool.
Using too many connections may just cause thrashing rather than get
more useful work done. In case an operation is attempted and all
connections are in use, the operation can block until a connection is
returned to the pool, or an error may be returned
Creating an SQL statement: Select, Insert,

Update, and Delete;
Write yourself
Authentication:
About User Authentication
User authentication is a process that finds whether a user is

who he or she is declared to be and verifies the privileges
assigned to that user. On the Firebox or XTM device, a user
account has two parts: a user name and a passphrase. Each
user account is associated with an IP address. This
combination of user name, passphrase, and IP address helps
the device administrator to monitor connections through the
device. With authentication, users can log in to the network
from any computer, but access only the network ports and
protocols for which they are authorized. The Firebox or XTM
device can then map the connections that start from a
particular IP address and also transmit the session name while
the user is authenticated.
You can create firewall polices to give users and groups access
to specified network resources. This is useful in network
environments where different users share a single computer
or IP address.
You can configure your Firebox or XTM device as a local

authentication server, or use your existing Active Directory
or LDAP authentication server, or an existing RADIUS
authentication server. When you use Firebox authentication
over port 4100, account privileges can be based on user name.
When you use third-party authentication, account privileges
for users that authenticate to the third-party authentication
servers are based on group membership.
The WatchGuard user authentication feature allows a user

name to be associated with a specific IP address to help you
authenticate and track user connections through the device.
With the device, the fundamental question that is asked and
answered with each connection is, "Should I allow traffic from
source X to go to destination Y?" For the WatchGuard
authentication feature to work correctly, the IP address of
the user's computer must not change while the user is
authenticated to the device.
In most environments, the relationship between an IP address

and the user computer is stable enough to use for
authentication. Environments in which the association between
the user and an IP address is not consistent, such networks
where applications are run from a terminal server, are usually
not good candidates for the successful use of the user
authentication feature.
WatchGuard supports Authentication, Accounting, and Access
control (AAA) in the firewall products, based on a stable
association between IP address and person.
The WatchGuard user authentication feature also supports

authentication to an Active Directory domain with Single Sign-
On (SSO), as well as other common authentication servers. In
addition, it supports inactivity settings and session time limits.
These controls restrict the amount of time an IP address is
allowed to pass traffic through the Firebox or XTM device
before users must supply their passwords again
(reauthenticate).
If you control SSO access with a white list and manage

inactivity timeouts, session timeouts, and who is allowed to
authenticate, you can improve your control of authentication,
accounting, and access control.
To prevent a user from authenticating, you must disable the

account for that user on the authentication server.
User Authentication Steps

An HTTPS server operates on the Firebox device to accept
authentication requests. To authenticate, a user must connect
to the authentication portal web page on the Firebox device
1. Go to either:
https://[device
interface IP address]:4100/
or
https://[device
hostname]:4100
An authentication web page appears.
2. Type a user name and password.
3. Select the authentication server from the drop-down

list, if more than one type of authentication is
configured.
The Firebox sends the name and password to the
authentication server using PAP (Password
Authentication Protocol).
When authenticated, the user is allowed to use the approved

network resources
Manually Close an Authenticated Session
Users do not have to wait for the session timeout to close

their authenticated sessions. They can manually close their
sessions before the timeout occurs. The Authentication web
page must be open for a user to close a session. If it is closed,
the user must authenticate again to log out.
To close an authenticated session:
1. Go to the Authentication portal web page:
https://[device
interface IP address]:4100/
or
https://[device host
name]:4100
2. Click Logout.
If the Authentication portal web page is

configured to automatically redirect to another
web page, the portal is redirected just a few
seconds after you open it. Make sure you logout
before the page redirects.
Allow Multiple Concurrent Logins
You can allow more than one user to authenticate with the
same user credentials at the same time, to one authentication
server. This is useful for guest accounts or in laboratory
environments. When the second user logs in with the same
credentials, the first user authenticated with the credentials
is automatically logged out. If you do not allow this feature, a
user cannot authenticate to the authentication server more
than once at the same time.
1. Go to the Authentication Settings dialog box.
2. Select the Allow multiple concurrent firewall

authentication logins from the same account check box.
For Mobile VPN with IPSec and Mobile VPN with SSL users,
concurrent logins from the same account are always supported
regardless of whether this check box is selected. These users
must log in from different IP addresses for concurrent logins,
which means that they cannot use the same account to log in
if they are behind a Firebox or XTM device that uses NAT.
Mobile VPN with PPTP users do not have this restriction.

Database Connectivity:: Computer Science Client Database Server Commands Data-Centric Connection Pooling

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Connectivity:: Computer Science Client Database Server Commands Data-Centric Connection Pooling

Uploaded by

Copyright:

Available Formats

Database Connectivity:

A database connection is a facility in computer science that allows

Connections are a key concept in data-centric programming. Since some

Connections are built by supplying an underlying driver or provider with

Databases, such as PostgreSQL, only allow one operation to be

Database connections are finite and expensive and can take a

Connection pooling is a technique designed to alleviate(improve) this

The connection object obtained from the connection pool is often a

This approach encourages the practice of opening a connection in an

In client/server architecture, on the other hand, a persistent connection is

Creating an SQL statement: Select, Insert,

User authentication is a process that finds whether a user is

You can configure your Firebox or XTM device as a local

The WatchGuard user authentication feature allows a user

In most environments, the relationship between an IP address

The WatchGuard user authentication feature also supports

If you control SSO access with a white list and manage

To prevent a user from authenticating, you must disable the

User Authentication Steps

An authentication web page appears.

2. Type a user name and password.

3. Select the authentication server from the drop-down

When authenticated, the user is allowed to use the approved

Manually Close an Authenticated Session

Users do not have to wait for the session timeout to close

1. Go to the Authentication portal web page:

If the Authentication portal web page is

Allow Multiple Concurrent Logins

1. Go to the Authentication Settings dialog box.

2. Select the Allow multiple concurrent firewall

You might also like