The information in this article applies to:
Transaction processing is an advanced feature that closely monitors your programs to recognize when a transaction is not completed properly. By identifying these problems the instant that they happen, transaction processing safeguards you from unfortunate events that would otherwise require you to restore your Tabs3 and PracticeMaster data from a backup.
This article discusses transaction processing, why it is important, and the technical details of how this significant database technology enhances Tabs3 and PracticeMaster Client Server Version (CSV) software starting with Version 14.2.
Transaction processing is used to ensure that all operations of a given database transaction completely succeed, thereby guaranteeing that the database remains in a consistent, reliable state. Although simple in theory, sophisticated software architecture techniques are required to implement transaction processing, and Client Server Version Software executes these techniques flawlessly.
A database transaction is a collection of operations grouped together into a single unit. For example, the act of transferring funds from one account to another might be considered a single database transaction, even though it involves several operations (i.e., crediting one account, debiting another account, etc.). As another example, updating a statement encompasses many operations (i.e., updating the client ledger, updating receipt allocation, updating productivity, moving each item from the work-in-process file to the archive files, etc.), but these operations are all grouped together and considered a single database transaction.
Atomicity is the core component of transaction processing. As the various operations within a database transaction take place, they technically do not affect the data until the entire transaction is committed. The term "committed" refers to a transaction having updated the data in a database. Therefore, as a database transaction is processed, it requires that all operations complete successfully before it is committed. If just one of the transaction's operations is unsuccessful (i.e., an error occurs or it is interrupted for any reason), then the database transaction does not commit, and therefore the data is untouched. This "all or none" approach is considered atomicity, whereby operations are grouped together into "atomic" units or transactions.
In Tabs3 and PracticeMaster Client Server Version (CSV) software, atomicity is applied to all programs or tasks within the software except those that are considered "Exclusive" or "Super Exclusive." For example, the Update Statements and Fee Data Entry programs in Tabs3 are examples of "Multi-Access" tasks because more than one person can use Tabs3 when these types of tasks are being performed. However, the Renumber Clients and Reindex Files programs are examples of "Exclusive" tasks because no other users can use Tabs3 when these types of tasks are being performed. Additional information regarding Exclusive, Super Exclusive, and Multi-Access tasks as well as a complete listing of these tasks can be found in KB Article R11174, "Network & Multi-User Functionality in the Software."
When a non-exclusive task is interrupted, in most cases, you simply need to perform the same task again. For example, if the Tabs3 Update Statements program is interrupted, you will be presented with a message indicating you simply need to run the Update Statements program again. If the same thing happened in non-CSV software, you would be presented with a message indicating you must restore your Tabs3 data files from a backup.
By utilizing atomicity, these critical programs can be safeguarded from unfortunate events that would otherwise require your data to be restored from a backup.
STI Server includes an Auto-Recovery feature that will automatically be performed if the STI Server software is not shut down correctly. This can occur for various reasons including power loss, hardware failure, the server being shut down incorrectly, etc. In the event that a database transaction was interrupted, the Auto-Recovery feature "rolls back" the database to its previous state before the database transaction began.
When a database transaction is committed, a record of its operations is written to a transaction log file. This transaction log file is used as a set of instructions for the database to reverse any operations that occurred since that state. For example, suppose an Auto-Recovery needs to be performed, and the transaction log file contains the following database transactions: add item A, add item B, subtract item C (in that order). To roll back the data, the database will add item C, subtract item B, and then subtract item A. As a result, the data now appears exactly as it did prior to those transactions taking place.
If a database transaction is interrupted (i.e., not fully committed), STI Server will detect this the next time it is started. Each time STI Server is started, it automatically scans the transaction log file to verify that all database transactions are committed. If it finds evidence of any database transactions that did not fully commit, STI Server performs an Auto-Recovery. This ensures the safety of your data, and minimizes any chance of data corruption.
Technical Note: Auto-Recovery is only necessary on the server level, not the client or workstation level. This is because atomicity already protects the database from interrupted database transactions on the client level. For example, if a workstation becomes disconnected from the server during a database transaction (e.g., due to power loss, network disconnection, fatal error, etc.), the server recognizes that all operations did not complete successfully, and does not allow the transaction to be committed.
THE INFORMATION PROVIDED IN THE SOFTWARE TECHNOLOGY, INC. KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. SOFTWARE TECHNOLOGY, INC. DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF SOFTWARE TECHNOLOGY, INC. OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
© 1999-2010 Software Technology, Inc. All rights
reserved. Terms of Use
The maker of Tabs3 and PracticeMaster
Tabs3, PracticeMaster, and the “pinwheel” symbol (
) are registered trademarks of Software Technology, Inc.
e-Mail Suggestions for the Knowledge Base to: kb@Tabs3.com
Technical Support via e-mail is not available.
Knowledge Base: http://support.Tabs3.com
Web Site: http://www.Tabs3.com