ClientServer - PowerPoint PPT Presentation

1 / 26
About This Presentation
Title:

ClientServer

Description:

Between objects in the same memory space the best thing we can say about them is ... Nuts and Bolts implementation details. SQL*Server. ADO/RDS. ASP. MTS. VB ... – PowerPoint PPT presentation

Number of Views:21
Avg rating:3.0/5.0
Slides: 27
Provided by: valt8
Category:

less

Transcript and Presenter's Notes

Title: ClientServer


1
Client/Server
  • A Personal View
  • Stuart Williams
  • Practitioner

2
The Version
  • The Goal
  • Applications that meet business needs
  • The Way
  • Use database technology to store the information
  • Use TCP/IP Sockets to link up the clients and the
    servers over the lan/wan/internet
  • Use the high level APIs so there is less code to
    maintain
  • Use a variety of RAD/JAD N-Tier techniques to
    knock out apps quickly

3
N-Tier Implementations
User Interface
Visual Basic
IE 4
Client
IIS 4
Business Logic
MTS Business Objects
Stored Procedures
Stored Procedures
Data Storage
Microsoft SQLServer
Server
4
Another View
5
Which One?
  • The "Horses for Courses" Rule.
  • If the client wants a web app, the get a web app.
  • If the client needs rich functionality, they get
    an app in visual basic.
  • The "Fish" rule.
  • If you want scalability you need more tiers.
  • If you really want to scale you need pooling.

6
Indispensable Technology - I
  • Relational Database Technology.
  • Theory Normalization, B-Trees, Statistics
  • The 'Structured Query Language' (SQL)
  • Defined by American National Standards Institute
    (ANSI).
  • Variously implemented by various vendors.
  • Serious emphasis on variously.
  • The four most common verbs work in almost the
    same way across vendors.

7
Indispensable Technology - II
  • Open Database Connectivity (ODBC)
  • A programmers interface that hides the varied
    implementation details of each of the database
    drivers. Provides an abstraction layer with a
    defined API. (A very complex one)
  • ActiveX data objects (ADO)
  • Provides programmers with a set of objects that
    provide an easy front to databases and drivers
    (including ODBC).

8
Indispensable Technology - III
  • Stored procedures
  • Script on the SQLServer that performs database
    and business functions.
  • VBScript/Active Server Pages (ASP)
  • Build Business logic via ASP. ASP technology
    allows the creation of robust server side
    applications. ASP is being ported to many
    platforms (mostly Unix).

9
Table Design For Performance
  • 4 Byte Integer (Long) Primary Keys
  • Do not use auto-incrementing primary keys for
    tables whose primary key is the foreign key of
    another table.
  • Avoid locking, consider the likelihood that a
    record will need to be updated by more than one
    user at a time.
  • Use surrogate keys rather than multi-part keys
    but watch out for duplicate records!
  • Defer memo fields to their own tables
  • When constructing SQL statements always put the
    memo fields last in the list of fields.

10
Optimization Vs. Normalization
  • Generally, starting with a properly normalized
    database is a good first step towards
    performance.
  • Selective de-normalization via introduction of
    addition foreign keys to selectively
    de-normalize.
  • This is because these additional keys allows for
    the reduction of the number of joins.
  • The trade off is that the additional foreign keys
    take up storage (small deal) and the additional
    indexes to maintain the referential integrity
    and/or speed relationships take additional time
    to maintain on insert/update and delete.

11
Microsoft Transaction Server
  • Performs pooling
  • Connection and Instance
  • Manages distributed transactions
  • Even across non-Microsoft platforms
  • Hosts middle tier business objects
  • Middle tier objects are built in VB or C and
    compiled to apartment threaded ActiveX DLLs.

12
Connection Pooling
  • Databases meter (price) by the number of
    connections. Connections are expensive.
  • Share connections, save money
  • Share connections, save time
  • Instancing connections is expensive in terms of
    time. By holding and reusing connections open to
    the SQLServer the expense of instancing them is
    reduced.

13
Instance Pooling
  • Creating objects is likewise expensive.
  • By tracking object creation and holding objects
    after they have been disposed, the next process
    can re-use the held object instances.
  • The most common objects that are instanced are
    ASP components and database connectors (ADO).

14
Transaction Coordination
  • MTS can coordinate transactions across multiple
    platforms
  • SQLServer and other databases
  • AS/400 and IBM mainframes
  • Unix(s)
  • Transactions can be nested or call other
    transactions.
  • Bottom Line All Succeed or All Fail.

15
General Design Principles - I
  • Less traffic over the wire is good.
  • Minimizing required bandwidth means there is more
    left over to scale.
  • Use TCP/IP because it is a routable, scalable
    protocol.
  • Do most of the application optimization at design
    time, instead of trying to fix performance issues
    at run time.

16
General Design Principles - II
  • Optimization strategies
  • Do not allow users to scroll through records,
    make them search and "drill down" to the detail.
  • Return only the rows absolutely needed
  • Return only columns to be displayed
  • Do calculations close to the data
  • Use action queries not recordsets when possible

17
Connection Use Strategies
  • For VB apps on the client the technique is to use
    a single connection object opened early (to avoid
    time penalty or repeated openings and closings).
    This connection instance will be used to connect
    other objects to the SQLServer. The connection
    is released at the last moment when the program
    ends. (Persistent Connection)
  • For web apps, the exact opposite strategy is
    used, because web pages are treated as MTS
    applications the best practice is to grab a
    connection as late as possible and dispose of it
    as soon as you can. If possible creating as few
    objects as you can. (Connectionless)

18
New Choices - RDS - I
  • The ability to create recordset objects that do
    not require a persistent connection, can be
    persistently stored on the client and yet still
    can be used to update data on the server means
    that you can have the benefit of a well
    connection interface (rich functionality and
    performance) with the benefits of a
    connectionless implementation (low resource use,
    scalability)
  • This Technology is called "Remote Data Services"
    (RDS)
  • RDS implements an ADO recordset with the
    properties of persistence and disconnection.

19
New Choices - RDS - II
  • RDS works across Port 80 so internet applications
    are possible that work across the firewall.
  • RDS allows for the creation of other object
    instances besides recordsets. Parameter passing
    between the client and the server use the
    recordset Meta-data format.
  • As it happens, passing parameters in a recordset
    is one of the most efficient ways to pass
    parameters in client/server systems.

20
The case for parameter passing - I
  • Properties are EVIL.
  • Between objects in the same memory space the best
    thing we can say about them is they are a chance
    for involuntary type conversion and run time
    errors
  • at worst (over the wire) every property let or
    set involves marshalling and a round trip across
    the wire.
  • Objects are forced to maintain state, hence don't
    scale. (This is hard for programmers to grasp,
    the traditional object oriented model is ideal,
    but in practice, simply evil. Truth. Stateless
    Components scale, objects don't.)

21
The case for parameter passing - II
  • Parameters are Good.
  • Reduced marshalling, one round trip, possibly
    (ideally) no state is kept at the object
    (scalable).
  • Pooling all the parameters in to a recordset
    means that the parameters are passed in an error
    checked, compressed and optimized way.
  • Recordsets allow a single call to an component to
    process multiple instances. Economical all the
    way around.
  • Components that reside in MTS are better still.

22
Record Change Management - I
  • For executed action queries, databases only
    create and hold locks for the duration of the
    update to the database. A VERY short time
    interval. This is optimal in most cases.
  • Less optimal but required or implemented,
    persistent locking is invoked. Typically, due to
    the creation of recordsets with explicit locking.
  • Locking, especially escalated over many records
    (page or worse yet, table locks) can result in
    deadlocks at worst (causing application failure)
    or poor performance as threads are caused to wait.

23
Record Change Management - II
  • In most cases if updateable recordsets are
    required or desired, optimistic batch locking is
    the best practice.
  • Behind the scenes, ADO (with or without RDS)
    maintains a local buffer (the size varies
    depending on cursor type.)
  • When a record is updated on the client the record
    is marked dirty. However, until explicitly asked
    to do so, or if the record would be flushed from
    the buffer the changes are not written to the
    server.
  • If there is NO explicit collision management in
    effect the "last in, wins" rule applies.

24
Record Change Management - III
  • If a timestamp field (a special column type) is
    present in the record, it is automatically
    included in the recordset, hence each record
    contains the exact date/time the record was last
    updated.
  • When a record in a recordset is changed and that
    change is propagated to the server, the timestamp
    field in the fetched recordset is compared to the
    existing one. If they do not match someone has
    modified the record since the original was
    fetched.

25
Record Change Management - IV
  • In this case a error will be raised to the
    client. The client has only one choice, to
    discard the recordset, re-fetch the records and
    then either abandon or re-apply the changes.
  • This choice is left up to the programmer, the ADO
    API exposes the list of records that did not
    successfully update.
  • In the case of an RDS recordset, this technique
    is very important as by definition, the entire
    recordset is on the client.

26
Topics, topics, topics.
  • More about database design.
  • Nuts and Bolts implementation details.
  • SQLServer
  • ADO/RDS
  • ASP
  • MTS
  • VB
Write a Comment
User Comments (0)
About PowerShow.com