Method and system for managing a distributed transaction process
Systems and methods for managing a distributed transaction process include an active transaction manager that manages transactions with an active database, a latent transaction manager that manages transactions with a merge database, a transaction log that reflects the set of transactions in the active database that are not affiliated with the transactions in the merge database, and a merge manager that uses the transaction log to determine whether to transfer control of the merge database to the active transaction manager. Systems and methods may further instruct the active transaction manager to halt transactions with the active database while the merge database is updated to reflect a set of transactions affiliated with the set of transactions in the transaction log, and instruct the active transaction manager to subsequently manage transactions to the active database and the merge database.
Latest ACS State & Local Solutions, Inc. Patents:
- Systems and methods for collecting information at an emergency vehicle
- APPARATUS AND METHODS FOR PROVIDING A PAYMENT SYSTEM OVER A NETWORK
- APPARATUS AND METHODS FOR PROVIDING A PAYMENT SYSTEM OVER A NETWORK
- Apparatus and methods for providing a payment system over a network
- Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
This application claims priority under 35 U.S.C. § 119 based on U.S. Provisional Application No. 60/414,645, filed Oct. 1, 2002 and U.S. Provisional Application No. 60/430,941, filed Dec. 5, 2002 the complete disclosures of which are incorporated herein by reference. In addition, this application is related to U.S. patent application Ser. No. 10/379,733 filed Mar. 6, 2003 and entitled “Systems And Methods For Electronically Processing Government Sponsored Benefits,” the complete disclosure of which is herein incorporated by reference.
TECHNICAL FIELDThis invention is related to data management, and more particularly to a method and system for managing a distributed transaction process, such as merging a database into a distributed transaction system. For example, one embodiment relates to recovering a distributed transaction process following the loss of one database member of the distributed transaction.
BACKGROUNDThe recent growth of networking technologies, as, for example, those associated with the Internet, has helped to cause a shift in the manner in which databases are maintained and used. For example, applications and associated databases that were typically local and in a one-to-one relationship have migrated to wide-area-networks (WANs) with many client applications associated with one centralized server and database. Despite numerous advantages associated with a centralized database configuration, one drawback associated with such a configuration is the vulnerability of the entire system to a single failure in the centralized database.
Such a failure may affect the security of the data stored and the reliability of the system in general. For example, financial institutions such as banks typically maintain proprietary customer data that is accessed for the purpose of both reading from existing customer records as well as writing to such records. Accordingly, the content of such a data collection is time dependent. As this customer data is accessed, it is vulnerable to system failures that may occur in the course of such access.
To avoid a complete catastrophic loss of customer data, a backup copy of the data is conventionally maintained. Where the primary data collection is time dependent and where backup copies are created at certain time intervals, the backup copies will correspond to “snapshots” of the primary data collection at specific intervals of time. During the time intervals between the creation of backup copies, there will occur some “latency” in the data content of the primary data collection and the backup data collection.
More recently, in an effort to address some of the security and reliability concerns mentioned above, there has been an interest in more complex networking configurations that are decentralized. One example of such a configuration makes use of what is referred to as a “distributed transaction.” Where a conventional transaction involves the reading, writing, or updating of a database record in a single database, a distributed transaction involves the reading, writing, or updating of a database record in a plurality of databases, where the plurality of databases may be redundant databases.
There are various technologies such as clustered operating and database systems, storage disk-based data replication, and database replication systems to provide instant redundant data. As used herein, “instant redundant data” implies a latency time between a first database and a second database (which may be a backup of the first database or merely a related database) that is optimally or arbitrarily small. For example, the latency time between a first database physically located in New York and a second database physically located in Los Angeles is at least equal to the amount of time required for communication between such locations.
Returning now to
As depicted in
If the databases are exact duplicates, then the transactions will generally be duplicate transactions. However, if the databases are not intended to be exact duplicates, but, rather, are intended to function with data in some one-to-one manner, then the transactions may not be exact duplicates. This dependency of the transaction upon the database is indicated in
Moreover, one skilled in the art will also appreciate, regardless of whether the databases used in the distributed transaction process are completely identical, the respective time associated with a transaction in each respective database will vary. The dependency of the time associated with a given transaction upon the database is indicated in
In addition, the “atomic” nature of the transaction is illustrated in the following example. Suppose that transaction manager 130 proposes a new transaction (transaction 171, for example, not depicted) and database instance 102 commits while database instance 112 is not able to commit. In that instance, transaction manager 130 will conventionally instruct resource manager 101 to rollback or undo the committed transaction 171(102) (not depicted) in database instance 102. In this manner, the “atomic” nature of the distributed transaction is preserved.
Even though the above example involves only two databases, one skilled in the art will appreciate that a distributed transaction may occur across any number of databases.
Conventionally, systems that support distributed transactions are costly, and platform and vendor dependent. In addition, conventional systems that support distributed transactions will only support automatic or manual fail-over. As used herein, a “fail-over” is a process whereby, for example, a database cannot participate in a distributed transaction due to some critical exception, that is, becomes “sick.” Following the critical exception, the transaction processing service will exclude the sick database and subsequently utilize the remaining active database(s) (the “healthy” databases).
As used herein, a “critical exception” refers to a failure of the ability of one database to continually record proposed transactions such that repeated undoing or roll-back of the transaction in other databases (due to the “atomic” nature of the process) is too costly for the system. One skilled in the art will appreciate that the “critical exception” level of failure of one database is generally determined by the judgment of the operator of the system. Although such automatic fail-over support may be provided by a vendor, there is no commercially available fail-back solution in which the sick database automatically recovers and merges back into the distributed system. As used herein, a “fail-back” refers to the process whereby, for example, the recovered sick database (which has been made “healthy”) is automatically merged back into future distributed transactions.
As stated above, in the case where any one database repeatedly fails to commit to a transaction, (a “sick database”) then transaction manager 130 will conventional switch into a “fail-over” mode where the sick database is automatically excluded from future proposed transactions and a notification may be generated for an administrator. An administrator may then determine the status of the sick database, perform whatever operation may be required in order that it is “healthy” again, and then manually merge the database back into the distributed system.
Such a manual merge operation may involve, for example, shutting the distributed system down in its entirety for a time period while the records in the healthy database are updated to be redundant with the records in the other databases. During this time period, the distributed transaction system is unavailable for use.
Accordingly, there is a need for a method and system to automatically merge a database into a distributed database system without manually shutting down the distributed transaction system.
SUMMARYMethods and systems consistent with the present invention relate to managing a distributed transaction process. One embodiment, for example, relates to recovering a distributed transaction process following the loss of one database member of the distributed transaction.
To support fail-back, one embodiment utilizes a transaction journal that stores all the updates to a first database and a second database. The embodiment also contemplates, without limitation, that the transaction journal entries are in the order in which the transactions occurred. For example, and without limitation, there may be a unique identifier for each transaction. In addition, and consistent with the present invention, the transaction journal may contain information about a database identifier for the last successful transaction.
During the recover process, one embodiment automatically detects any discrepancies between each failed databases and the information in the transaction journal. The embodiment may then automatically send the transactions from the transaction journal to those failed databases in order for the failed databases to catch up to the healthy database serving as the active database. In the meantime the active databases can continue accept the ongoing live transactions (the “active” transactions) and the transaction journal continues the logging process.
Once the discrepancy between the recovered database and the active database is reduced to a configurable threshold, the embodiment temporarily halts all transactions to the active databases. During the period in which all transactions to the active databases are halted, the recovered databases may complete the catch-up process reducing the data latency between the databases to zero, or arbitrarily close to zero. Accordingly, within seconds, for example, the databases should be completely synchronized. At this point, the embodiment contemplates an automatic resumption of distributed transactions using all active and recovered databases.
Additional objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and together with the description, serve to explain the principles of the invention.
In the drawings:
A method and system for managing a distributed transaction process is described below. In the following description, numerous exemplary details are set forth to provide an understanding of a preferred embodiment of the present invention.
In a preferred embodiment depicted in
The system in
In the embodiment depicted in
Accordingly, in the system depicted in
As mentioned above, latent transaction manager 234 in
Again, for the purpose of illustration only, we assume that the time it takes to apply all N1 transactions to merge database instance 222 extends from time 292 to a time 392. The resulting system at time 392 is depicted in
The system depicted in
In each instance, the respective journals and logs are consistent with the system of
Merge manager 232 in a preferred embodiment may record this information in order to decide whether to transfer control of merge database instance 222 to active transaction manager 236 and active resource manager 225. For the purpose of illustration only, we assume that merge manager 232 at the time depicted in
Accordingly, as was the case in depicting the system at time 292 in
Accordingly, in a second step consistent with the present invention, latent transaction manager 234 applies the N2 transactions in discrepancy transaction log 335 to merge database instance 222. During the time period that this is occurring, active transaction manager 236 again continues to accept additional transactions to apply to database instance 202 and database instance 212.
Again, for the purpose of illustration only, we assume that the time it takes to apply all N2 transactions to merge database instance 222 extends from time 392 to a time 492. The resulting system at time 492 is depicted in
Again, the system depicted in
Again, the respective journals and logs are consistent with the system of
Again for the purpose of illustration only, we assume that merge manager 232 at the time depicted in
One skilled in the art will appreciate that the series of iterations depicted in
Specifically, the coordinates on the abscissa are related to the number of discrepancy transaction iterations that latent transaction manager 234 applies to merge database instance 222. The iteration labeled “1” on the abscissa corresponds to the transformation of the system from
The sequence of iterations depicted in
As stated earlier with regard to
Alternatively, merge manager 232 may decide to transfer control of merge database instance 222 to active transaction manager 236 and active resource manager 225 according to asymptote 570. For example, asymptote 570 is illustrated to correspond to a selected overall discrepancy transaction distribution time on the right ordinate. Accordingly, merge manager 232 may determine that the amount of time required to update merge database instance 222 with the discrepancy transactions in discrepancy transaction log 435 is at or below the threshold depicted in
Merge manager 232 may calculate a discrepancy transaction distribution time associated with an asymptote 570 according to a selected algorithm. For example, merge manager may be able to estimate the amount of time per transaction according to the existing affiliated times 302(222)-392(222), or in any other manner. Merge manager 232 may also examine the current range of distribution times represented by, for example, affiliated times 302(202)-392(202) in transaction journal 350 (
On the other hand, if the number of discrepancy transactions is not zero, then a determination may be made as to whether the cost of pausing the system, updating the database to be merged, and proceeding is at an acceptable level. This may be performed, for example, by determining whether the estimated time to update the database to be merged is at or less than a characteristic distribution time (a step 708). If this is the case, the processing of the active distributed transactions to the active databases is temporarily paused (a step 712), the merge database is updated with the discrepancy transactions (a step 714), then control of the database to be merged is handed over the active transaction manager (for example, active transaction manager 236 and active resource manager 225) (a step 718) and the system may proceed with subsequent distributed transactions including the merged database (step 720).
Alternatively, if the cost of pausing the system, updating the database to be merged, and proceeding is at not at an acceptable level (step 708), then the system may simply update the database to be merged with the current set of discrepancy transactions while the active databases continue to accept the active transactions (a step 710). Following this step, the system may then return to step 704 by identifying the new set of transactions that have been committed to by the active databases (database instance 202 and database instance 212, for example) but that have not yet been committed to be the database to be merged (merge database instance 222, for example). The method may then proceed as described above with respect to step 706.
For example, and without limitation, one application that the present invention may be applied to includes the maintenance of multiple databases associated with Electronic Benefits Transfer and Electronic Payment Processing and Information Control (EPPIC) systems as described related U.S. patent application Ser. No. 10/379,733 filed Mar. 6, 2003 and hereinabove incorporated by reference.
When implemented to run on a JAVA Virtual Machine (JVM) in the EPPIC system, an embodiment of the present invention utilizes a persistence package to handle all high-level database access. The persistence package, for example, allows created objects and variables to continue to exist and retain their values between runs, and is dynamically configurable by the system management and by programmatic APIs (Application Program Interface). In one embodiment in the EPPIC system, persistence logging is used to ensure that database instances can be merged back into a distributed transaction process. For example, a persistence log database may be associated with each database instance. The physical database associated with the persistence log database may be the same physical database as the database instance. In such a case, when the database instance goes inactive, the persistence log database also goes inactive.
Moreover, the embodiment of the present invention in the disclosed EPPIC system is generally used for failover/failback purposes only. That is, the embodiment of the present invention for managing distributed transaction process is not generally used to migrate the entire contents of a database onto a blank new database. For example, in the embodiment of the present invention used in the EPPIC system, the persistence log databases are purged once they are no longer needed, such as when all EPPIC databases have committed to a transaction. To create a new database, however, one could manually take one database offline (including its persistence log database) and make a copy of the entire contents of the database and the corresponding persistence log database onto a new database. Afterwards, the entire system, including the new database with its corresponding persistence log database, may be resynchronized according to the system and method of the present invention.
In addition, in the embodiment of the present invention in the EPPIC system, all of the components of the EPPIC system that utilize the persistence layer and that perform the writes to the EPPIC databases should run within the same JVM. Moreover, those components of the EPPIC system that do not need to write to the EPPIC databases should be initialized to not use the persistence layer in their respective configuration files. One skilled in the art should appreciate, however, that the above recited implementation in the EPPIC system may be generalized according to the system and methods disclosed herein. Moreover, the invention is not limited to implementations in the JAVA programming environment. Other implementations are, of course, contemplated such as in C++, C, and C#, etc.
CONCLUSIONThis invention is related to data management, and more particularly to a method and system for managing a distributed transaction process following a failure of such a process due to the loss of one database member of the distributed transaction.
The foregoing description of an implementation of the invention has been presented for purposes of illustration and description. It is not exhaustive and does not limit the invention to the precise form disclosed. One skilled in the art will appreciate from the foregoing description that modifications and variations are possible in light of the above teachings or may be acquired from practicing of the invention. For example, the steps associated with the present invention may be implemented as a combination of hardware and software or in hardware alone. Furthermore, although certain aspects of the present invention are described as being stored in memory, one skilled in the art will appreciate that these aspects may also be stored on or read from other computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or CD-Rom; a carrier wave from the Internet; or other forms of RAM or ROM. Moreover, although certain aspects of the present invention are described with regard to database instances associated with long-term storage, one skilled in the art will appreciate that the database instances may also be associated with memory records loaded into temporary storage, such as RAM. Accordingly, the invention is not limited to the above-described embodiments, but instead is defined by the appended claims in light of their full scope of equivalents.
Claims
1. A method for managing a distributed transaction system, comprising:
- managing transactions with at least an active database by an active transaction manager, where the active database reflects an application of a set of active transactions;
- managing transactions with a merge database, where the merge database reflects an application of a first subset of the set of active transactions;
- generating discrepancy transaction log information that reflects a set of discrepancy transactions that is distinct from the first subset of active transactions, the discrepancy transactions consisting of active transactions not yet applied to the merge database;
- determining whether to transfer control of the merge database to the active transaction manager; and
- if a determination is made not to transfer control of the merge database to the active transaction manager, instructing a latent transaction manager to apply the discrepancy transactions to the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log information, and instructing the active transaction manager to continue to manage transactions with the active database; and
- if a determination is made to transfer control of the merge database to the active transaction manager,
- instructing the active transaction manager to halt transactions with the active database, instructing the latent transaction manager to update the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log information, and instructing the active transaction manager to manage transactions to the active database and the merge database.
2. The method of claim 1, wherein determining whether to transfer control of the merge database to the active transaction manager comprises:
- determining a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log information;
- comparing the log number to a target value; and
- transferring control of the merge database to the active transaction manager if the log number bears a predetermined relationship to the target value.
3. The method of claim 1, wherein determining whether to transfer control of the merge database to the active transaction manager comprises:
- determining a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log information;
- comparing the log number to a target value; and
- transferring control of the merge database to the active transaction manager if the log number is less than the target value.
4. The method of claim 1, wherein determining whether to transfer control of the merge database to the active transaction manager comprises:
- calculating a characteristic distribution time associated with the active transaction manager;
- calculating a time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log information; and
- transferring control of the merge database to the active transaction manager if the time value bears a predetermined relationship with the characteristic distribution time.
5. The method of claim 4 wherein calculating a characteristic distribution time comprises:
- determining an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- setting the characteristic distribution time equal or approximately equal to the amount of time per transaction.
6. The method of claim 1, wherein determining whether to transfer control of the merge database to the active transaction manager comprises:
- calculating a characteristic distribution time associated with the active transaction manager;
- calculating a time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log information; and
- transferring control of the merge database to the active transaction manager if the time value is less than the characteristic distribution time.
7. The method of claim 6 wherein calculating a characteristic distribution time comprises:
- determining an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- setting the characteristic distribution time equal or approximately equal to the amount of time per transaction.
8. The method of claim 1, wherein managing transactions with at least an active database comprises:
- generating unique identifiers for active transactions.
9. The method of claim 1, wherein managing transactions with at least an active database comprises:
- managing transactions in association with a Java Virtual Machine.
10. The method of claim 1, wherein managing transactions with at least an active database comprises:
- managing transactions with said active database stored in RAM.
11. The method of claim 1, wherein managing transactions with a merge database comprises:
- managing transactions with said merge database stored in RAM.
12. The method of claim 1, wherein managing transactions with at least an active database comprises:
- managing a persistence log.
13. A system, including at least one processor and memory, for managing a distributed transaction process comprising:
- an active transaction manager that manages transactions with at least an active database, where the active database reflects an application of a set of active transactions;
- a latent transaction manager that manages transactions with a merge database, where the merge database reflects an application of a first subset of the set of active transactions;
- a discrepancy transaction log that reflects a set of discrepancy transactions that is distinct from the first subset of active transactions; the discrepancy transactions consisting of active transactions not yet applied to the merge database;
- a merge manager that uses the transaction log to determine whether to transfer control of the merge database to the active transaction manager;
- where, if the merge manager does not transfer control of the merge database to the active transaction manager, the latent transaction manager is configured to apply the discrepancy transactions to the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log; and
- where, if the merge manager transfers control of the merge database to the active transaction manager, the latent transaction manager is configured to update the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log, and the active transaction manager is configured to halt transactions with the active database while the latent transaction manager updates the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log, and the active transaction manager is further configured to subsequently manage transactions to the active database and the merge database.
14. The system of claim 13, wherein the merge manager comprises:
- a counter configured to generate a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the log number is approximately equal to a target value.
15. The system of claim 13, wherein the merge manager comprises:
- a counter configured to generate a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the log number is less than a target value.
16. The system of claim 13, wherein the merge manager comprises:
- a time calculator configured to calculate a characteristic distribution time associated with the active transaction manager;
- a merge time calculator configured to calculate a merge time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the merge time value is approximately equal to the characteristic distribution time.
17. The system of claim 16, wherein the time calculator comprises:
- an active time calculator configured to calculate an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- a results processor configured to set the characteristic distribution time equal or approximately equal to the amount of time per transaction.
18. The system of claim 13, wherein the merge manager comprises:
- a time calculator configured to calculate a characteristic distribution time associated with the active transaction manager;
- a merge time calculator configured to calculate a merge time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the merge time value is less than the characteristic distribution time.
19. The system of claim 18, wherein the time calculator comprises:
- an active time calculator configured to calculate an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- a results processor configured to set the characteristic distribution time equal or approximately equal to the amount of time per transaction.
20. The system of claim 13, wherein the active transaction manager comprises:
- an identifier generator configured to generate unique identifiers for active transactions.
21. The system of claim 13, where the active transaction manager is implemented in association with a Java Virtual Machine.
22. The system of claim 13, where said active database is stored in RAM.
23. The system of claim 13, where said merge database is stored in RAM.
24. The system of claim 13, where the active transaction manager manages a persistence log.
25. A tangible computer-readable storage medium embodying computer-readable code for instructing a system that manages a distributed transaction process, the computer-readable code comprising:
- an active transaction manager, where the active transaction manager manages transactions with at least an active database and where the active database reflects an application of a set of active transactions;
- a latent transaction manager, where the latent transaction manager manages transactions with a merge database, where the merge database reflects an application of a first subset of the set of active transactions;
- a discrepancy transaction log that reflects a set of discrepancy transactions that is distinct from the first subset of active transactions, the discrepancy transactions consisting of active transactions not yet applied to the merge database; and
- a merge manager that uses the transaction log to determine whether to transfer control of the merge database to the active transaction manager; where, if the merge manager does not transfer control of the merge database to the active transaction manager, the latent transaction manager is configured to apply the discrepancy transactions to the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log; and where, if the merge manager transfers control of the merge database to the active transaction manager, the latent transaction manager is configured to apply the discrepancy transactions to the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log; and the active transaction manager is configured to halt transactions with the active database while the latent transaction manager updates the merge database to reflect the set of discrepancy transactions reflected in the discrepancy transaction log, and the active transaction manager is further configured to subsequently manage transactions to the active database and the merge database.
26. The tangible computer-readable storage medium of claim 25, wherein the merge manager comprises:
- a counter configured to generate a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the log number is approximately equal to a target value.
27. The tangible computer-readable storage medium of claim 25, wherein the merge manager comprises:
- a counter configured to generate a log number reflecting a total quantity of discrepancy transactions in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the log number is less than a target value.
28. The tangible computer-readable storage medium of claim 25, wherein the merge manager comprises:
- a time calculator configured to calculate a characteristic distribution time associated with the active transaction manager;
- a merge time calculator configured to calculate a merge time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log information; and
- a controller configured to transfer control of the merge database to the active transaction manager if the merge time value is approximately equal to the characteristic distribution time.
29. The tangible computer-readable storage medium of claim 28, wherein the time calculator comprises:
- an active time calculator configured to calculate an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- a result calculator configured to set the characteristic distribution time equal or approximately equal to the amount of time per transaction.
30. The tangible computer-readable storage medium of claim 25, wherein the merge manager comprises:
- a time calculator configured to calculate a characteristic distribution time associated with the active transaction manager;
- a merge time calculator configured to calculate a merge time value for the merge database to reflect a set of discrepancy transactions reflected in the discrepancy transaction log; and
- a controller configured to transfer control of the merge database to the active transaction manager if the merge time value is less than the characteristic distribution time.
31. The tangible computer-readable storage medium of claim 30, wherein the time calculator comprises:
- an active time calculator configured to calculate an amount of time per transaction for the active transaction manager to manage transactions with the active database; and
- a results processor configured to set the characteristic distribution time equal or approximately equal to the amount of time per transaction.
32. The tangible computer-readable storage medium of claim 25, wherein the active transaction manager comprises:
- an identifier generator configured to generate unique identifiers for active transactions.
33. The tangible computer-readable storage medium of claim 25, wherein the active transaction manager is implemented in association with a Java Virtual Machine.
34. The tangible computer-readable storage medium of claim 25, wherein said active database is stored in RAM.
35. The tangible computer-readable storage medium of claim 25, wherein said merge database is stored in RAM.
36. The tangible computer-readable storage medium of claim 25, wherein the active transaction manager manages a persistence log.
4341951 | July 27, 1982 | Benton |
5461217 | October 24, 1995 | Claus |
5530855 | June 25, 1996 | Satoh et al. |
5536045 | July 16, 1996 | Adams |
5559887 | September 24, 1996 | Davis et al. |
5577121 | November 19, 1996 | Davis et al. |
5640561 | June 17, 1997 | Satoh et al. |
5737539 | April 7, 1998 | Edelson et al. |
5864822 | January 26, 1999 | Baker, III |
5924094 | July 13, 1999 | Sutter |
5930759 | July 27, 1999 | Moore et al. |
5953719 | September 14, 1999 | Kleewein et al. |
6014635 | January 11, 2000 | Harris et al. |
6061660 | May 9, 2000 | Eggleston et al. |
6067522 | May 23, 2000 | Warady et al. |
6112182 | August 29, 2000 | Akers et al. |
6115715 | September 5, 2000 | Traversat et al. |
6129275 | October 10, 2000 | Urquhart et al. |
6169974 | January 2, 2001 | Baumgartner et al. |
6189011 | February 13, 2001 | Lim et al. |
6199074 | March 6, 2001 | Kern et al. |
6230145 | May 8, 2001 | Verderamo et al. |
6233617 | May 15, 2001 | Rothwein et al. |
6266648 | July 24, 2001 | Baker, III |
6282522 | August 28, 2001 | Davis et al. |
6299062 | October 9, 2001 | Hwang |
6343271 | January 29, 2002 | Peterson et al. |
6446089 | September 3, 2002 | Brodersen et al. |
6446092 | September 3, 2002 | Sutter |
6615190 | September 2, 2003 | Slater |
6616189 | September 9, 2003 | Raming |
6694447 | February 17, 2004 | Leach et al. |
6766302 | July 20, 2004 | Bach |
6808111 | October 26, 2004 | Kashef et al. |
6873995 | March 29, 2005 | Benson et al. |
6896618 | May 24, 2005 | Benoy et al. |
6999936 | February 14, 2006 | Sehr |
7054838 | May 30, 2006 | Sutton et al. |
7083084 | August 1, 2006 | Graves et al. |
7136835 | November 14, 2006 | Flitcroft et al. |
7149724 | December 12, 2006 | Flanagan et al. |
7165049 | January 16, 2007 | Slater |
7174315 | February 6, 2007 | Phillips et al. |
7206805 | April 17, 2007 | McLaughlin, Jr. |
7222097 | May 22, 2007 | Bellosguardo |
7290056 | October 30, 2007 | McLaughlin, Jr. |
7319986 | January 15, 2008 | Praisner et al. |
20010034702 | October 25, 2001 | Mockett et al. |
20020010679 | January 24, 2002 | Felsher |
20020107849 | August 8, 2002 | Hickey et al. |
20020156676 | October 24, 2002 | Ahrens et al. |
20030009355 | January 9, 2003 | Gupta |
20030074234 | April 17, 2003 | Stasny |
20030093283 | May 15, 2003 | Morsa |
20030101136 | May 29, 2003 | Wheeler et al. |
20030163755 | August 28, 2003 | Fung et al. |
20030177150 | September 18, 2003 | Fung et al. |
20030216967 | November 20, 2003 | Williams |
20030225760 | December 4, 2003 | Ruuth et al. |
20040093303 | May 13, 2004 | Picciallo |
20040128245 | July 1, 2004 | Neal et al. |
20060116960 | June 1, 2006 | Gillin et al. |
20060218206 | September 28, 2006 | Bourbonnais et al. |
20070061251 | March 15, 2007 | Watkins |
0088639 | December 1984 | EP |
0216521 | November 1993 | EP |
0493894 | March 1996 | EP |
2323060 | September 1998 | GB |
06-032086 | February 1994 | JP |
WO 96/25814 | August 1996 | WO |
WO 96/41287 | December 1996 | WO |
WO 97/10560 | March 1997 | WO |
WO 97/17212 | May 1997 | WO |
WO 97/30409 | August 1997 | WO |
WO 97/39424 | October 1997 | WO |
WO 97/41541 | November 1997 | WO |
WO 98/05011 | February 1998 | WO |
WO 99/06967 | February 1999 | WO |
WO 01/29708 | April 2001 | WO |
- Bowen, Cathy, “Welfare Agencies Seek Benefits From Chip Cards,” Card Technology, V7, N1, pp. 40-44, Jan. 2002 (5 page print-out from Dialog®).
- Sanders, Bob, “New Electronic Systems Let Your Fingers Do The Banking,” New Hampshire Business Review (Manchester, NH), V18, N7, p. 1 (dated Mar. 29, 1996) (5 page print-out from Dialog®).
- Business Wire, “Broadbase Software, BroadVision, Interwoven and Verity Create State-of-the-Art Portal for the State of California” (Sacramento, CA), Jan. 9, 2001 (5 page print-out from FindArticles.com).
- Business and Finance, “Creating the Digital Citizen,” May 10, 2001 (2 page print-out from Dialog®).
- PCT/US03/09931 Search Report dated Jan. 2, 2004 (8 pages).
- USDA (US Department of Agriculture), www.fns.usda.gov, obtained from Internet Archive Wayback Machine www.archive.org, Date Range: Aug. 3, 2002-Aug. 24, 2002. “Facts about the Food Stamp Program” (9 pages).
- Excerpt from International Search Report PCT/US03/29982, dated Jun. 21, 2004, indicating “Documents Considered to be Relevant” (1 page).
- Joulia Dib et al., “Electronic Benefit Transfer (EBT) Programs: Best Practices To Serve Recipients,” Goldman School of Public Policy, University of California at Berkeley, Aug. 2000, pp. i-v and 1-93.
- Bellare, M., “VarietyCash: A Multi-purpose Electronic Payment System,” Proceedings of the 3rd USENIX Workshop on Electronic Commerce, Aug. 31-Sep. 3, 1998, pp. 9-24.
- Burmansson, Frank, “Travel Cards in the Year 2000: The Helsinki Region Ushers in the Smart Card Era,” Urban Public Transportation Systems, Proceedings of the First International Conference, Committee on Public Transport, Urban Transportation Division, ASCE, Mar. 21-25, 1999, pp. 229-239.
- Block, Valerie, “Belgians Promoting Their Smart Card in U.S. (Banksys),” American Banker, vol. 160, No. 156, Aug. 15, 1995 (2 pages).
- Parker, “Visa International Charges Ahead With Stored-Value Card,” InfoWorld, vol. 17, No. 42, p. 78, Oct. 16, 1995 ( 4 pages).
- “American Express: Last Minute Shoppers Face Grim Reality,” M2 Presswire, Dec. 17, 1999 (1 page).
- “An AmEx Stored-Value Quest Leads To A Disney Debit Card Pact,” The Gale Group, Jun. 25, 1998 (3 pages).
- Kline, Alan, “Calif. Bank Buys Control Of Electronic Paycheck Firm Series: 9,” American Banker, vol. 162, Iss. 204, p. 8, Oct. 22, 1997, New York, NY (2 pages).
- Bell, Stephen, “Direct Electronic Cash—Coming Soon to a Store Near You,” Independent Business Weekly, May 20, 1998, New Zealand (4 pages).
- Wenninger, John et al., “The Electronic Purse,” Federal Reserve Bank of New York, Current Issues in Economics and Finance, vol. 1, No. 1, Apr. 1995 (6 pages).
- Jaben, Jan, “Finland Sprints Ahead with Smart Cards,” Credit Collection News, Nov. 6, 1997 (4 pages).
- Burger, Andrew, “Hong Kong: Smart Card Hotbed,” The Gale Group, Jul. 1998 ( 7 pages).
- Hansell, Saul, “Mastercard's ‘Smart Card’ Builds Support,” The New York Times, Late Edition—Final, p. 3, col. 1, Dec. 5, 1996 (2 pages).
- “A New Card Dispenser Gives the Unbanked a Debit Option,” Debit Card News, Apr. 27, 1998 (2 pages).
- “Prepay? It's in the Cards,” The Gale Group, Apr. 1994 (3 pages).
- “Report to the Congress on the Application of the Electronic Fund Transfer Act to Electronic Stored-Value Products,” Board of Governors of the Federal Reserve System, Federal Research Board Publications, Mar. 1997, pp. 19-27 (13 pages).
- “Smart Cards Finally Get Respect From U.S. Banks,” Bank Network News, vol. 12, Iss. 7, p. 1, Aug. 26, 1993, Chicago (3 pages).
- King, Julia, “Teen Buyers Now Have New Ways To Pay Online,” Computerworld, 33, 43, ABI/INFORM Global, Oct. 25, 1999, p. 40.
- McGee, John, “Towards A Cashless Society,” Business and Finance, Business and Finance Magazine, Nov. 27, 1997 (2 pages).
- “Visa Introduces a Prepaid International Money Card,” American Banker, Dec. 7, 1994 (3 pages).
- Gregg, Leigh, “Will You Be Ready For E-Cash?,” Credit Union Executive Journal, vol. 38, Iss. 1, Jan./Feb. 1998, p. 12 (4 pages).
- “Business Plan,” WallyCard.com, pp. 1-14 (retrieved from http://leeds-faculty.colorado.edu/moyes/bplan/Samples/WallyCard/WallyCard.pdf on Sep. 8, 2008).
- “Claimant Guide,” Utah Department of Workforce Services Unemployment Insurance, pp. 1-20 (retrieved from http://jobs.utah.gov/ui/jobseeker/claimguide.asp on Sep. 8, 2008).
- “A CBO Study, Emerging Electronic Methods for Making Retail Payments,” The Congress of the United States, Congressional Budget Office, U.S. GPO, Jun. 1996 (62 pages).
- “EMV Migration Economics—Comparing Native and MULTOS smart card choices,” MULTOS, pp. 1-17 (retrieved from www.multos.com/downloads/Whitepaper—EMV—Migration—Economics—Platform—Comparison.pdf on Sep. 8, 2008).
- “EMV: The Journey From Mag-Stripe to Chip Cards,” Secure Payment (retrieved from http://www.silicon-trust.com/trends/tr—emv.html on Sep. 8, 2008) (5 pages).
- Hancock, Diana et al., “Payment transactions, instruments, and systems: A survey,” Journal of Banking & Finance 21 (1998) pp. 1573-1624.
- Hargreaves, Margaret et al., “The Evaluation of the Expanded EBT Demonstration in Maryland, vol. 1: System Startup, Conversion and Expansion,” May 1994 (retrieved from www.abtassociates.com/reports/D19940002.pdf on Sep. 8, 2008) (150 pages).
- “Hypercom Partners with ACS to Deploy 15,000 ePic ICE 5500 Card Payment Terminals in Support of Texas EBT System,” Business Wire, Jun. 13, 2000 (retrieved from http://findarticles.com/p/articles/ mi—m0EIN/is—2000—June—13/ai—62696512 on Sep. 8, 2008) (3 pages).
- Magid, Larry, “Credit Cards, Internet team up to give kids lessons in how to manage spending,” The Mercury News, Family Tech (retrieved from http://www.larrysworld.com/articles/sjm—credicards.htm on Sep. 8, 2008) (3 pages).
- McDonald, Noreen, “Multipurpose Smart Cards in Transportation: Benefits and Barriers to Use,” Dec. 8, 2000, pp. 1-27 (retrieved from www.uctc.net/scripts/countdown.pl?630.pdf on Sep. 8, 2008).
- Oliveira, Victor et al., “All Food Stamp Benefits To Be Issued Electronically,” Food Assistance and Welfare Reform, Jan.-Apr. 1998, pp. 35-39.
- “PocketCard,” CardWeb.com, Jul. 22, 1999 (retrieved from www.cardweb.com/cardtrak/news/1999/july/22a.html on Sep. 8, 2008) (1 page).
- “PocketCard Inc.'s Product Launch at Internet World Summer 99; High-Tech Visa Card Ends Expense Account Headaches,” Business Wire, Jul. 21, 1999 (retrieved from http://findarticles.com/p/articles/ mi—m0EIN/is—1999—July—21/ai—55217741 on Sep. 8, 2008) (4 pages).
- “Pocketcard Visa, A new twist on teaching teens about credit,” Epinions.com, Jun. 11, 2000 (retrieved from www99.epinions.com/finc-review-2C14-9FACA4F-39447D2B-prod5 on Sep. 8, 2008) (2 pages).
- “Prepaid Cards,” Working Group on EU Payment Systems, May 1994, republished on Dec. 21, 1997 (retrieved from http://jya.com/EU—prepaid—cards.html on Sep. 8, 2008) (11 pages).
- “Security of Electronic Money,” Committee on Payment and Settlement Systems and the Group of Computer Experts of the Central Banks of the Group of Ten Countries, Bank for International Settlements (Aug. 1996) (70 pages).
- “Stored Value Cards: An Alternative for the Unbanked?,” Federal Reserve Bank of New York, Jul. 2004 (retrieved from www.ny.frb.org/regional/stored—value—cards.html on Sep. 8, 2008) (5 pages).
- “Stored Value Card Systems,” Information for Bankers and Examiners, Bulletin to Chief Executive Officers of all National Banks, Department and Division Head, and all Examining Personnel, OCC 96-48, Sep. 10, 1996 (retrieved from www.occ.treas.gov/ftp/bulletin/96-48.txt on Sep. 8, 2008) (10 pages).
- “Telephone Card Guide,” KARS Unlimited (retrieved from www.kars-unlimited.com/svc—guide.htm on Sep. 8, 2008) (1 page).
- Tual, Jean Pierre et al., “Electronic Commerce, Electronic Purse and Standardisation,” MUST 97 (retrieved from www.jptual.club.fr/downloads/must197 on Sep. 8, 2008) (29 pages).
- Turner, Nigel, “Bank Launches Salary Card,” Smart Card News, Smart Card News Ltd., Brighton, England, vol. 8, No. 4, p. 71, Apr. 1999 (20 pages).
- “Visa Latin American and Caribbean—The History of Visa,” (retrieved from http://www.visalatam.com/e—aboutvisa/acerca—historia.jsp on Sep. 8, 2008) (1 page).
Type: Grant
Filed: Aug 29, 2003
Date of Patent: Feb 17, 2009
Patent Publication Number: 20040088298
Assignee: ACS State & Local Solutions, Inc. (Washington, DC)
Inventors: Kevin Zou (Austin, TX), Josh A. Wiles (Round Rock, TX), Pasquale Solitro (Round Rock, TX), Zheng Zhu (Austin, TX)
Primary Examiner: John E Breene
Assistant Examiner: Joshua Bullock
Attorney: Finnegan, Henderson, Farabow, Garrett & Dunner, LLP
Application Number: 10/650,994
International Classification: G06F 7/00 (20060101); G06F 17/30 (20060101); G06F 12/00 (20060101);