Shared Distributed Memory : the Workspace Model
Didier DONSEZ, Liming CHEN, Pascal FAUDEMAY†
Laboratoire HEUDIASYC - Université de Technologie de Compiègne
†Laboratoire MASI- Université Pierre et Marie Curie (Paris VI) e-mail : {donsez,lchen}@hds.univ-compiegne.fr
e-mail : [email protected]
The OO-DBMS Architecture
Comm layer Application
Comm layer Application
Comm layer Comm layer
Database Archive
Client Cnxn Client Cnxn
Clients
Servers
Network
Client / Server Model fits well to LANs with powerful Workstations
ERSADS’95 Shared Distributed Memory : the Workspace Model 3
But there are some limitations ...
Does not fit to Heterogeneous LAN / WAN Networks
Use of Check In / Check Out Mechanisms
Need for Query Shipping
• Weak Clients
Nomadic PCs, Walkstations
• Security and Confidentiality
The Nested Transaction Model [Moss85]
T1121
DataBase T111 T112
T11 T12
T1
T21 T22
T221 T222
T2
T1
T11 T12 T111 T112
T1121
T2 T21 T22
T221 T222
ERSADS’95 Shared Distributed Memory : the Workspace Model 5
The Workspace Model
Goal :
• Extend Moss’ Model
• Map Client and Server Processes
on a graph of “extended” nested transactions
Transaction Model the Workspace Model = +
Process Model
WS Model : The Transaction Model
Moss' Model +
• simultaneous "sister" transactions
• multiple parents transactions
• retaining or passing export
T1 T3 T4 T6 T7
T8
T2 T3 T4 T6 T7
T8
T5
T1
T3 T4 T5 T6 T7
T8
T2
access toV1 access to V2
∪ =
ERSADS’95 Shared Distributed Memory : the Workspace Model 7
WS Model : Retaining Transaction / Passing Transaction
Retaining Export
Moss' Commit
Passing Export
Behave as a Data Cache
Retaining
Passing Passing
Passing
Retaining
T commit T commit
WS Model : The Process Model
Restrict the graph of extended Transactions
to efficiently implement the Workspace Process
Volume Vj
to Volume VO to Volume Vn
A Workspace Process to a Client WS to another Client WS
2 Server STs Application ST
N Sub Transactions attached to
1 Main Transaction MT
a Server WS another Server WS
Transaction Database View
ERSADS’95 Shared Distributed Memory : the Workspace Model 9
Instanciations of the Workspace Model
A Workspace may be
• a standalone machine,
• a client,
• a server or
• both client and server
Instanciations of some architectures :
Standalone Database Client / Server Database
Client / Server Database “à la SHORE”
WAN Front-end
Client / Server Database Architecture
the database is distributed on N servers : each client is directly connected to N servers
MT Client WS
V1
Server WS Vn
ST ST
MT
Client WS
a sequential application
Server WS MT
ST ST
MT
ST ST
ERSADS’95 Shared Distributed Memory : the Workspace Model 11
Client / Server “à la SHORE” (U. of Wisconsin)
each server exports its part to the N-1 servers
a n d merges all parts and export them to its connected clients
V1
MT
Client WS a sequential
application
Server WS
MT
ST ST
MT ST
Vn ST MT
ST ST
Server WS Client WS
Client / Server with WAN Front-End
Client Workstation
LAN
Volume V0
Volume Vn
Client Workstation
WAN
Front End=
Dept. Server
Server Server V0 Vn
Front End WS Client WS
Server WS
MT
a sequential application
MT
ST ST
MT
ST ST
MT
ST ST
MT
Retaining Export for Check In / Check Out
ERSADS’95 Shared Distributed Memory : the Workspace Model 13
Mixing Data and Query Shipping
Data Shipping
➠ moves confidential data to unsecured clients
Server WS ST Client WS
MT
oid? lock/value query {oid|nvalue}
Query Shipping
➠ involves bigger servers
back to the Mainframe Model
Merging Data-Query Shipping =
☞ 2 kinds of access permissions
• 1 for operation on server
• 1 for data export
☞ consistency data between Client MT and Server ST
Implementation
2 implementations
WEA - YOODA
True MultiThreading
parallelism (CPU,IO) and asynchronous communications
Memory Mapping
page buffering, implicit 2P locking
Callback 2 Phase Locking
lock cache in the client
C++ interface (ODMG like)
ERSADS’95 Shared Distributed Memory : the Workspace Model 15
Futures Works
• Merge of WEA-YOODA
• Applications
• Document Database on heterogeneous networks
• Cooperative Information Systems
• possible extension to Asynchronous Video Stream
Mixing Data and Query Shipping
Data Shipping
➠ moves confidential data to unsecured clients
Query Shipping
➠ involves bigger servers
back to the Mainframe Model
Merging Data-Query Shipping =
☞ 2 kinds of access permissions
• 1 for operation on server
• 1 for data export
☞ consistency data between Client MT and Server ST
