Firebird supports operations across multiple databases under the control of a single transaction. It implements two-phase commit (2PC) automatically, to ensure that the transaction will not commit the work in one database unless it is possible to commit it in the others. Data is never left partly updated.
In the first phase of a two-phase commit or rollback, Firebird prepares to commit (or roll back) the work for each database by splitting the transaction into sub-transactions, one for each database, and posting the changes to each. At this point, the sub-transactions are all in a “transient” state. If the first phase completes, then the second phase flags each sub-transaction for committing or rolling back, as the case may be, in the order in which the parts were prepared.
If network interruption or a disk crash makes one or more databases unavailable, causing the two-phase commit to fail during the second phase, sub-transactions left behind will be in a transient state, flagged as neither committed nor rolled back. Within each individual database, these sub-transactions that never completed the second phase (became committed or rolled back) are recognized as being in a “limbo” state.
Because rows in a database sometimes become inaccessible because of their association with a transaction that is “in limbo,” it is important to resolve these transactions.
Until a limbo transaction is finished (by being committed or rolled back) it remains “interesting” to Firebird, which keeps statistics on unfinished transactions. Recovering a limbo transaction means committing it or rolling it back. The gfix tool can recover limbo transactions and let you deal with them interactively.
Cross-database transactions can use a lot of server resources. In Embedded SQL (ESQL), Firebird provides language support in the form of the USING clause, for optionally limiting the databases a transaction is permitted to access. DSQL does not provide language support. DSQL interfaces can use special API structures in the transaction parameter block for limiting multi-database transactions in various ways. Some data access component classes provide access to these options through properties.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.