Databases Reference
In-Depth Information
could apply to virtually any solution that runs on a general purpose computer, which
shares resources among clients, or a server sharing resources between multiple virtual
machines. But the key differentiator of multitenancy is a smaller granularity for sharing,
which results in more efficient use of resources.
There are a couple of additional implications of multitenancy. One factor is that a mul‐
titenant architecture really doesn't matter—the underlying computer resources are hid‐
den in the cloud, so what does a tenant care about whether a solution is multitenant or
not? It's a good point, but the overall efficiency of a cloud offering has an impact on how
the offering can be priced and how well it scales.
The other implication is that multitenancy, whether done with schemas (for ) or some
other architecture, is different from traditional architectures. This difference has an
impact on whether application systems that have been designed for different architec‐
tures may not work optimally, or at all, in these new environments.
Stateless
Another key technical factor comes with the introduction of the Internet, which runs
on the HTTP protocol. HTTP is a stateless protocol, which means that each commu‐
nication using this protocol is a separate transaction. Since one of the characteristics of
the cloud is the use of the Internet, cloud solutions are also stateless by nature.
This stateless nature may not make a big difference, as transactions are frequently re‐
stricted to a single communication as a good design practice. But sometimes this limi‐
tation can have a significant impact. Consider the case of an application that returns a
page of results from a multipage result set. The page looks fine, with appropriate Next
and Previous buttons to scroll through results. But be aware that each request for another
page runs the underlying query again, in a different transaction. Any changes that have
taken place since the previous run of the query will be in the new result set. So if the
first page contained 10 rows, and one of those rows was deleted between the fetch of
the first page and the fetch of the second, the second page would not start with the
11
th
row from the previous result set, but with what had been the 12
th
, since one row is
now gone.
An Oracle Database, whether in the cloud or not, has a way to over‐
come this stateless limitation, at least for queries.When you ask for the
first page, you can retrieve the System Change Number for the trans‐
action, and then use this for a Flashback Query for subsequent re‐
quests to emulate full stateful data integrity over the stateless HTTP
protocol.
