Data Management in Application Servers

Data Management

Essential to distribute and maintain data outside of the monolithic backend to improve scalability and performance
Facilitated by relaxing traditional ACID properties of the data
Especially appropriate for reference and transient data
WebLogic accomplishes this using five basic service types, which differ in their treatment of internal state
The J2EE APIs are implemented in terms of these service types

Caching Strategies

Flush at regular intervals (TTL)
Best when data is frequently updated
Flush after an update completes
Best when data is infrequently updated
Implemented using multicast
Manual flush API to allow notification of “backdoor” updates
Pre-load and refresh (Not currently supported)
Interesting to persist the data remotely
Refresh at regular intervals (data warehouse) or after update (data replication)
Facilitates querying through the cache
Worthwhile primarily for data that will be hit many times per refresh

Transactional Reads

Authoritative copy of the data in a database
The service maintains a copy in memory between invocations
Reads by any client use the in-memory copy
The challenge: Maintain consistency with the database given updates that go through other instances or the “backdoor”
Possible solutions
Distributed concurrency control
Centralized lock manager
Use the database
Partition so exactly one copy of each data item

Optimistic Services

Use the database to implement optimistic concurrency control for transactions with writes
No protection for read-only transactions
Upon commit, compare the before-and-after values of fields that were read and throw a concurrency exception if they don’t match
Can be done fairly efficiently using UPDATE-WHERE
Does not require modification of the database schema
To minimize the likelihood of such exceptions, flush after updates occur (but not within the transaction)
Does not ensure serializability in that, for example, an increment and decrement of the same field will look like it was not modified
This is a feature in that it allows safe but non-serializable transactions

Availability of Singleton Services

Harden individual servers
Multiple execute queues / thread pools
Deny rather than degrade service
Redundant networks
Restart failed and ailing servers
Lifecycle and health monitoring APIs
Under control of a nanny daemon or HA framework
Upgrade without interruption
Rolling upgrade of servers
Hot redeploy of applications
Migrate singleton services
Manually from the Administrative console
Automatically using distributed agreement to avoid split-brain syndrome