Title: A Replication Framework for
1 A Replication Framework for Program-to-Program
Integration across Unreliable Networks and its
Implementation in a Servlet Container
Alberto Bartoli Milan Prica Etienne Antoniutti
di Muro
DEEI Università di Trieste
2Building Blocks
Programmercode
JMiramare
Replication algorithm
JBora
Group Communication Middleware (GC layer)
Spread
3What JMiramare offers?
- Operations from each client are executed in
the - same order in which they were issued by the
client.
- If the service replica SR receives multiple
copies of a given - update request, SR executes the operation
only once.
- Nota Bene
- Multiple copies of a given request could be
received by different replicas
- There are NO assumptions about the timing
policy of client - retransmissions.
4How it works? (Premises)
- Data structures of the service replica are kept
in volatile storage. - Data structures are replicated and kept in sync
at all servers in the - primary partition.
- Each client is connected to a single replica at
a time. - A replica can execute a request only if it is
up-to-date for that object. - If a replica is unable to execute the request,
it redirects the client to - another replica.
5... Premises
- Each replica executes read operations locally.
- A replica can perform updates only if it is a
member of the groups - primary partition.
- Updates involve multicasting to the other
replicas the new version - of the object and the last response sent to
the client. - A client that does not receive the response for
an update may - submit the very same request immediately.
-
- Replicas that enter the primary partition must
first gain the - up-to-date version of server replica data.
6Implementation Issues
7Request
- Params input params of the method
- clientId system-wide unique identifier
- serviceHandleobjId counter of the
successful - updates from that client
8Response
- Status OK, UNABLE, UNKNOWN
- Result invoked method return value
- NewHandle new value of the successful
- updates counter
- Alternatives network addresses of some
- of the service replicas
9Data Structures of a Server Replica
- obj the actual object replicas
- versionTable number of updates applied to each
- object (version number)
- clientTable for each (clientId, objId),
- (lastVersionNumber, lastResponse)
- canUpdate boolean flag, true only if the
replica can execute updates
- currV the last view received
10Algorithm Overview
- When a replica bootstraps, it spawns
- MainT() thread
- Listening thread
- When a new request comes in, the connection
- is associated with a ClientSessionT() thread
- ClientSessionT() thread processes each
- request as follows
11Execution Path of an HTTP Request
Consistency
Update
Servlet Service
Tomcat AXIS
Not Up To Date
localCall()
Shared data between the MainT and the ClientT.
Main Thread
12Main thread (Principal tasks)
- Receives a message m from ClientSessionT()
- // via grp.localCall() ? JBora
- Upon receiving the multicast m, updates the
object and - all necessary data structures
- MainT() at the replica that sent the multicast
also executes - grp.localRespond() // thus awakening the
ClientSessionT().
13We want to figure out how to integrate our code
with the common replication framework?
14JMiramare?
ComponentMonitor
ComponentHandle
call()
call()
Replication Framework Proposal
Proxy
Normal Axis chain Handlers disabled
static call()
TxHandler
WSMon
Handler
Service Object
handleReq()
handleReq()
handleResp()
handleResp()
AXIS
15?
16Request handling logic (detailed)
Add Entry in ClientTab
New Client ?
Server Up To Date?
Req Read ?
No
No
Yes
req
// update
No
Yes
SERVICE
resp
ltUNABLE, redirectgt
ltOK, resultgt
17Request handling logic (cont.)
Duplicate req?
Can update?
No
Yes
req
// update
No
Yes
resp
ltUNABLE, redirectgt
ltOK, resultgt
18Request handling logic (cont.)
GC
Main Thread propagate()
SERVICE Update (Copy)
// can update
Clone Obj. (Make a Copy)
grp.LocalCall (to MainThr)
req
Yes
No
OK?
resp
Undo
ltOK, resultgt
ltUNKNOWNgt