U.S. patent application number 11/955229 was filed with the patent office on 2008-04-24 for system and method for optimistic caching.
This patent application is currently assigned to BEA SYSTEMS, INC.. Invention is credited to Dean Bernard Jacobs, Adam Messinger, Seth White, Rob Woollen.
Application Number | 20080097997 11/955229 |
Document ID | / |
Family ID | 27616675 |
Filed Date | 2008-04-24 |
United States Patent
Application |
20080097997 |
Kind Code |
A1 |
White; Seth ; et
al. |
April 24, 2008 |
SYSTEM AND METHOD FOR OPTIMISTIC CACHING
Abstract
Transactions are granted concurrent access to a data item
through the use of an optimistic concurrency algorithm. Each
transaction gets its own instance of the data item, such as in a
cache or in an entity bean, such that it is not necessary to lock
the data. The instances can come from the data or from other
instances. When a transaction updates the data item, the optimistic
concurrency algorithm ensures that the other instances are notified
that the data item has been changed and that it is necessary to
read a new instance, from the database or from an updated
instance.
Inventors: |
White; Seth; (San Francisco,
CA) ; Messinger; Adam; (San Francisco, CA) ;
Jacobs; Dean Bernard; (Berkeley, CA) ; Woollen;
Rob; (San Francisco, CA) |
Correspondence
Address: |
FLIESLER MEYER LLP
650 CALIFORNIA STREET
14TH FLOOR
SAN FRANCISCO
CA
94108
US
|
Assignee: |
BEA SYSTEMS, INC.
2315 North First Street
San Jose
CA
95131
|
Family ID: |
27616675 |
Appl. No.: |
11/955229 |
Filed: |
December 12, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11339180 |
Jan 25, 2006 |
7328322 |
|
|
11955229 |
Dec 12, 2007 |
|
|
|
10340023 |
Jan 10, 2003 |
7020684 |
|
|
11339180 |
Jan 25, 2006 |
|
|
|
60349464 |
Jan 18, 2002 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.008; 707/E17.007 |
Current CPC
Class: |
G06F 12/0815 20130101;
Y10S 707/99952 20130101; Y10S 707/99938 20130101 |
Class at
Publication: |
707/008 ;
707/E17.007 |
International
Class: |
G06F 17/00 20060101
G06F017/00 |
Claims
1. A computer implemented system for concurrently caching instances
of a data item, comprising: a database capable of storing a data
item; a plurality of cluster nodes capable of executing a
transaction using the data item; a cache for cluster nodes
executing a transaction, the cache capable of storing an instance
of the data item; and an optimistic caching algorithm running
concurrently on multiple cluster nodes, the algorithm capable of
directing the clusters node to notify other cluster nodes when
updating the data item in the database.
2. The computer implemented system according to claim 1, wherein:
the cluster nodes are further capable of checking the data item in
the database before updating the data item.
3. The computer implemented system according to claim 1, wherein:
the instances of data items are stored as enterprise beans at the
caches.
4. The computer implemented system according to claim 3, wherein:
the instances of data items are stored as enterprise java beans at
the caches.
5. The computer implemented system according to claim 4, wherein:
the enterprise java beans load themselves from the database.
6. The computer implemented system according to claim 4, wherein:
the enterprise java beans store themselves in the database.
7. The computer implemented system according to claim 1, wherein:
the currency of the data is checked when a transaction commits.
8. A computer implemented system for concurrently caching instances
of a data item, comprising: a plurality of nodes capable of
executing a transaction wherein the transaction is adapted to use
an instance of a data item derived from a data item stored in a
database; at least one cache associated with the plurality of nodes
being capable of storing the instance of a data item; and an
optimistic caching algorithm running concurrently on at least some
of the plurality of nodes, the optimistic caching algorithm capable
of directing nodes to notify other nodes when updating the data
item in the database.
9. The system of claim 8, further comprising: a plurality of
caches, wherein each cache is associated with one of the plurality
of nodes.
10. The system of claim 8, wherein: the instances of data items in
the plurality of caches can be updated from at least one of the
data item stored in the database and the instance of the data item
associated with another of said plurality of caches.
11. The computer implemented system according to claim 8, wherein:
the cluster nodes are further capable of checking the data item in
the database before updating the data item.
12. The computer implemented system according to claim 8, wherein:
the instances of data items are stored as enterprise beans at the
caches.
13. The computer implemented system according to claim 12, wherein:
the instances of data items are stored as enterprise java beans at
the caches.
14. The computer implemented system according to claim 13, wherein:
the enterprise java beans load themselves from the database.
15. The computer implemented system according to claim 13, wherein:
the enterprise java beans store themselves in the database.
16. The computer implemented system according to claim 8, wherein:
the currency of the data is checked when a transaction commits.
17. A computer implemented system for concurrently caching
instances of a data item, comprising: a plurality of nodes capable
of executing a transaction wherein the transaction is adapted to
use an instance of a data item derived from a data item stored in a
database; at least one cache associated with the plurality of nodes
being capable of storing the instance of a data item; and an
optimistic caching algorithm running concurrently on at least some
of the plurality of nodes, the optimistic caching algorithm capable
of directing nodes to notify other nodes when updating the data
item in the database, data items are stored as enterprise beans at
the at least one cache.
18. The computer implemented system according to claim 17, wherein:
the instances of data items are stored as enterprise java beans at
the caches.
19. The computer implemented system according to claim 18, wherein:
the enterprise java beans load themselves from the database.
20. The computer implemented system according to claim 18, wherein:
the enterprise java beans store themselves in the database.
Description
CLAIM OF PRIORITY
[0001] This application is a continuation of U.S. patent
application Ser. No. 11/339,180, entitled "SYSTEM AND METHOD FOR
OPTIMISTIC CACHING" by White et al., filed Jan. 25, 2006; which is
a continuation of U.S. patent application Ser. No. 10/340,023, now
U.S. Pat. No. 7,020,684 entitled "SYSTEM AND METHOD FOR OPTIMISTIC
CACHING" by White et al., filed Jan. 10, 2003; which claims
priority from U.S. Provisional Patent Application No. 60/349,464
entitled "SYSTEM AND METHOD FOR OPTIMISTIC CACHING" by White, et
al. filed Jan. 18, 2002, incorporated herein by reference.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document of the patent disclosure, as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever.
CROSS REFERENCE TO RELATED PATENT DOCUMENTS
[0003] The following co-pending U.S. patent documents are assigned
to BEA Systems, Inc., the assignee of the present application, and
these documents are hereby incorporated herein by reference. U.S.
patent application Ser. No. 10/340,067 filed Jan. 10, 2003, now
U.S. Pat. No. 6,978,278 to Seth White et al. and entitled, "System
and Method for Heterogeneous Caching" and U.S. patent application
Ser. No. 10/340,301 filed Jan. 10, 2003, now U.S. Pat. No.
7,136,879 to Seth White et al. and entitled, "System and Method for
Read-Only Entity Bean Caching"; and U.S. patent application Ser.
No. 09/975,590 filed Oct. 11, 2001, to Dean Jacobs et al. and
entitled "Data Replication Protocol".
FIELD OF THE INVENTION
[0004] The invention relates to the caching of data for multiple
transactions.
BACKGROUND
[0005] In a system where multiple users desire concurrent access to
the same data, a concurrency model such as exclusive concurrency
can be used to provide such access. In such a model, each server
instance manages an exclusive lock on a primary key and any data
associated with that key. This lock is held for the length of the
transaction when invoked for a transaction. In the case of a
non-transactional invoke, such as for a method that requires access
to, but will not update, the data, the lock is held until the
method completes. In a clustered environment, it is possible that a
given primary key is active in multiple servers. In such a
situation, concurrency control is typically provided by the
database.
[0006] The exclusive concurrency model works well in a single
server system in which the server has exclusive access to the
database. A sharing value, such as "db-is-shared" can be set to
false, such that the any read of the data can read from an instance
in an in-memory cache instead of reading from the database.
[0007] Problems arise; however, as the exclusive concurrency model
requires the use of deadlocks. Deadlocking can occur when users
have locks on separate objects, and one of the users is trying to
acquire a lock on an object that is locked by another user. Beans
holding instances of the data can also deadlock themselves if the
beans are called within a transaction and subsequently called
without a transaction.
[0008] Other systems provide the ability for each transaction to
activate a unique instance of the data. These systems do not
provide concurrency control within the application server, however,
but rely on the database for concurrency. This database concurrency
model is an improvement over exclusive concurrency, but it is still
necessary to hit the database for every transaction. This approach
can still strain system resources under load.
BRIEF SUMMARY
[0009] Systems and methods in accordance with embodiments of the
present invention can overcome these and other deficiencies in the
prior art by providing an optimistic approach to concurrency. In
one embodiment, a first instance of a data item is read into a
first cache for a first transaction. The first data item can be
read from the database or from the cache for a previous
transaction. A second instance of the data item is read into a
second cache for a second transaction. The second cache can read
from the first cache, from the database, or from a cache for a
previous transaction. The data item in the database can then be
updated by committing changes for one of the transactions. The
changes can also be committed to the cached instance of the data
item for that transaction. An optimistic concurrency algorithm
directs the updating cache to notify the other cache that the data
item has changed and that the other instance is not current. The
outdated cache can then drop its instance of the data item and read
a new instance. The outdated cache can read the new instance from
the database, from the updated cache, or from a cache for a
previous transaction.
[0010] Other features, aspects and objects of the invention can be
obtained from a review of the specification, the figures, and the
claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a diagram of a system in accordance with one
embodiment of the present invention.
[0012] FIG. 2 is a diagram of a system in accordance with another
embodiment of the present invention.
[0013] FIG. 3 is a flowchart showing the steps of a method in
accordance with the embodiment of the FIG. 1.
DETAILED DESCRIPTION
[0014] Systems and methods in accordance with one embodiment of the
present invention can overcome deficiencies in prior art
concurrency models by utilizing "optimistic caching" or "optimistic
concurrency". Using optimistic concurrency, it is not necessary for
each transaction to read from the database and consume system
resources unnecessarily.
[0015] The approach is referred to herein as "optimistic" because a
server instance does not get a lock on the data being used by a
transaction. Transactions are optimistic about the fact that no
changes are going to be made to the data while it is being used by
that transaction. Under this belief, there is no need to lock the
data since it will not change during the transaction. Since the
data is not locked, it can be used concurrently by multiple
users.
[0016] In order to assure the accuracy of transactions using that
data, however, it will be necessary to determine whether the
underlying data actually changed before transactional changes are
written to the database.
[0017] An invalidation scheme can be used to facilitate optimistic
caching in a clustered environment, such that multiple machines in
a cluster can run an optimistic algorithm in parallel. When changes
are made, the machines can communicate with each other that a
change has occurred, and can indicate what those changes are. This
can help to avoid an optimistic conflict or exception at the end of
a transaction. XML can be used with such a system, as XML provides
a declarative way for a user to indicate that optimistic caching is
to be used.
[0018] Such a system is shown in FIG. 1. A data item 102 is stored
in a database 102. User 106 and user 110 may both want access to
the data item 102 concurrently. Since the data item is not locked,
an instance of the data item can be read into a cache or bean
instance 104 for user 106, and a second instance can be read into a
cache or bean instance 108 for user 110. If user 106 updates the
data item 102, the optimistic algorithm can direct cache 104 to
notify cache 108. The algorithm can also instruct the transaction
for user 106 to update the instance of the data item in cache 104.
If the instance in cache 104 is updated, cache 108 can read a new
instance from cache 104. If cache 104 is not updated, cache 110 can
read from the database 100.
[0019] There can be multiple nodes in a cluster that are able to
access and make changes to the data in the database, as shown in
FIG. 2. In order to make efficient use of a cluster, an application
can evenly utilize any available cluster nodes 204, 206, 208. For
instance, a user 200 that wishes to utilize data in the database
202 can be directed to work through node 204. The user is not aware
of which node is being utilized, as the nodes appear to the user as
a single server. An object can migrate from one node to another in
support of even load distribution.
[0020] It can be beneficial for these nodes to notify each other
about any changes made to data. In FIG. 2, node 204 is shown to be
able to send an update message to nodes 206 and 208 in the event
that the user 200 updates data in the database 202. Such
information can prevent other nodes from having to wait until the
end of a transaction to find out that the data has changed. If a
node does not find out about the change until the end of a
transaction, the node will need to rollback the transaction, obtain
the updated state of the data, and restart the processing of the
transaction. This notification of nodes in a cluster can save both
time and resources by preventing the reprocessing of transactions.
Different schemes can be used that allow the nodes to notify
themselves of changes in the data.
[0021] FIG. 3 shows steps for a method that could be used with a
system in accordance with the embodiment of FIG. 1. In this method,
an instance of a data item is read into a first cache for a first
transaction 300. An instance of the data item is then read from the
first cache into a second cache for a second transaction 302. One
of the transactions can update the data item in the database by
committing changes to the data item, and can also update the
associated instance in cache 304. A notification can then be sent
to the cache for the other transaction notifying the cache that the
data item has changed 306. That cache can then drop its instance of
the data item and read a new instance from the database or from the
updated cache 308.
[0022] Certain operations can be done outside of a transaction. One
such operation involves suspending the active transaction while
reading data. This operation can be a global transaction, for
example, that spans multiple nodes about the network and can be
committed using a two-phase commit algorithm.
[0023] "Creates" and "removes" can be done within the context of
global transactions, such that if a global transaction rolls back
then the operations can be rolled back as well. Long-term locks can
be held during these operations. During the load, a copy of the
data can be made so that the data is read during a short-term
transaction. An initial copy of the data being read can be made.
The transaction can then actually update a different copy of the
data, such that at the end of the transaction those copies can be
compared with what is in the database, in order to help determine
whether to commit the transaction.
Enterprise JavaBeans
[0024] This optimistic caching can also be done with Enterprise
JavaBeans (EJBs). An EJB has a life cycle, and certain embodiments
of optimistic caching work within the context of this life cycle.
The EJBs can load themselves from the database and can store
themselves in the database. The EJBs can also undergo other
operations, such as loading, storing, creating, removing,
passivating, and activating. EJBs can also read data in a local
transaction. This allows the EJBs to read data items without
acquiring long-term locks on the data.
Caching Between Transactions
[0025] In one embodiment, optimistic caching allows for the caching
of data between separate transactions. In prior art systems where
every transaction reads from the database, entity beans holding
instances of the data do not perform any better than stateless
session beans. In order to better utilize the functionality and
advantages of entity beans, caching can be done between
transactions to the extent possible.
[0026] One way to accomplish between-transaction caching is to read
data in a local transaction so there is no need for long-term
locks. At the end of the transaction, the data can be checked to
determine if anyone has made any changes. In one such system, a
"db-is-shared" or equivalent tag can be replaced with a tag such as
"AppServerCachingEnabled", which can allow the caching of entity
beans between transactions when AppServerCachingEnabled has a value
of "true".
[0027] In a more optimistic embodiment for caching between
transactions, data is not read at the beginning of a transaction.
It is assumed that what is in cache from a previous transaction is
still current with what is in the database. The currency of the
data is not checked until the end of the transaction. This allows
the transaction to use what is already in cache memory, which can
greatly increase the speed of the transaction. If the transaction
attempts to commit and finds the data has changed, it can update
the data in cache so that the next transaction can read from cache
and have the appropriate value.
CMP Optimistic Concurrency without Caching
[0028] There are other optimistic concurrency embodiments that can
support the EJB 2.0 Container-Managed Persistence (CMP)
specification, and can be used with or without caching between
transactions.
[0029] In an optimistic concurrency approach without caching, each
transaction can activate its own bean instance. There is no locking
within the application server. Two new tags can be used, such as
"OptimisticVerifyModifiedFields" and "OptimisticVerifyReadFields".
With these options, a database read can occur as a separate local
transaction. In the case of OptimisticVerifyReadFields, the update
statement can verify that every field that was read in the
transaction matches the current content in the database.
OptimisticVerifyModifiedFields can be used to check only the fields
that have been updated. The transaction can abort if the update
conditions fail. If the transaction is a read-only transaction, it
will not produce an update statement and there will be no
verification.
[0030] Such a system can utilize special abstract methods for CMP
fields such as "increment", "decrement", and
"decrementGreaterThan". For example, if there is an item being
purchased at an online store by several users concurrently, each
individual transaction simply wants to decrease the inventory
amount by one unit. Each transaction is able to commit the update
as long as the inventory is greater than zero units. The
transaction does not care about how many units are in inventory, as
long as there is at least one. Therefore, an operator could be used
such as:
[0031] public abstract void decrementInventoryIfGreaterThan(int
n);
A SQL statement could then be issued such as:
[0032] update set inventory=inventory-1 where inventory>0 and
pk=`item`;
CMP Optimistic Concurrency with Caching
[0033] The OptimisticVerifyModifiedFields and
OptimisticVerifyReadFields could also be used as the basis for
clustered entity bean caching. A server could keep a cache that
associates a primary key and field group with cached data. In a CMP
2.0 implementation, a field group can be a set of container-managed
fields. When one member of a group needs to be read from the
database, the entire group is read. By default, the CMP fields can
be in a single group, but this can be changed using a deployment
descriptor, for example.
[0034] When an entity bean reads a field group, it can ask the
cache for the field group. If the cache has the field group in
memory, it can return the cached data instead of fetching the data
from the database. When an updating transaction commits, the
changes can be entered into the cache as well as into the database.
This allows the cache to have the most recent data without having
to hit the database. The cache can also measure the hit rate and
optimistic rollback rate. These statistics can be used to drop or
pre-fetch cached data.
Multicast Invalidation
[0035] It can be useful to prevent some of the optimistic rollbacks
that can occur if, for example, a first server updates a value and
then a second server reads from the second server's outdated or
"stale" cache. One way to prevent this is to send invalidation
messages between the caches. When an update commits, an
invalidation can be sent to the other caches, such as by multicast.
The message can contain, for example, the JNDI name, the primary
key, and the field group number.
[0036] When an ejb cache receives an update message, the cache can
drop the corresponding field group from its cache. If this field
group has a high hit rate, the cache can pre-fetch the new
version.
[0037] While these invalidation messages can help prevent
optimistic rollbacks, they do not ensure correctness. The
predicated update can be used to ensure that the read or modified
fields are consistent with that which is still in the database.
[0038] The foregoing description of preferred embodiments of the
present invention has been provided for the purposes of
illustration and description. It is not intended to be exhaustive
or to limit the invention to the precise forms disclosed. Many
modifications and variations will be apparent to one of ordinary
skill in the relevant arts. The embodiments were chosen and
described in order to best explain the principles of the invention
and its practical application, thereby enabling others skilled in
the art to understand the invention for various embodiments and
with various modifications that are suited to the particular use
contemplated. It is intended that the scope of the invention be
defined by the claims and their equivalence.
* * * * *