Technical Interview Questions and Answers :: Wipro

A transaction is a very small unit of a program and it may contain several lowlevel tasks. A transaction in a database system must maintain Atomicity, Consistency, Isolation, and Durability − commonly known as ACID properties − in order to ensure accuracy, completeness, and data integrity.

• Atomicity − This property states that a transaction must be treated as an atomic unit, that is, either all of its operations are executed or none. There must be no state in a database where a transaction is left partially completed. States should be defined either before the execution of the transaction or after the execution/abortion/failure of the transaction.


• Consistency − The database must remain in a consistent state after any transaction. No transaction should have any adverse effect on the data residing in the database. If the database was in a consistent state before the execution of a transaction, it must remain consistent after the execution of the transaction as well.


• Durability − The database should be durable enough to hold all its latest updates even if the system fails or restarts. If a transaction updates a chunk of data in a database and commits, then the database will hold the modified data. If a transaction commits but the system fails before the data could be written on to the disk, then that data will be updated once the system springs back into action.


• Isolation − In a database system where more than one transaction are being executed simultaneously and in parallel, the property of isolation states that all the transactions will be carried out and executed as if it is the only transaction in the system. No transaction will affect the existence of any other transaction.

ACID properties are 4 important properties of a transaction that a DBMS must ensure to maintain data in the case of concurrent access

Yes

osi model means( open system interconnection)  .it has seven layers 1.physical layer 2.data link layer 3.network layer 4. transport layer 5. session layer 6.presentation layer 7. application layer

  1) Designer

  2) Developer

  3) MWS

  4) Brokers

  5) PubSub Models

  6) Deployer

  7) Trading Network

  8) Integration Server

  9) Triggers, Adapters and file polling ports.

An adapter notification monitors a specified database table for changes, such as an insert, update, or delete operation, so that the appropriate Java or flow services can make use of the data, such as sending an invoice or publishing it to the Integration Server.
JDBC Adapter notifications are polling-based. That is, the Integration Server will invoke the notification periodically based on the polling interval that you specify when you schedule the notification.

Enabled: The polling notification performs as scheduled.
Suspended: The polling notification is removed from the scheduler but the database trigger and buffer table are not dropped.
Disabled: The polling notification is removed from the scheduler and the database trigger and buffer table are dropped.

Most adapter notifications, such as Insert Notifications and Update Notifications, can use the Exactly Once notification feature. This feature ensures that notification data will not be duplicated even if a failure occurs during processing. This is achieved by assigning unique IDs for each publishable document. After a processing failure, the Integration Server checks for duplicate records in storage and ignores any duplicate IDs.

Note: Stored Procedure Notifications do not support the Exactly Once notification feature because they do not use publishable document unique IDs

Notification Types
There are six types of notifications: Insert, Update, Delete, Basic, Stored Procedure, and Ordered Notifications. They vary in how they are structured and operate, as described in the following sections.
Insert Notifications, Update Notifications, and Delete Notifications use a combination of triggers and buffer tables to capture events that happen on specific tables in a database. You configure the triggers and buffer tables when you configure the notifications.
These types of notifications operate similarly, with the exception of the type of SQL operation (insert, update, or delete) that they monitor. The adapter creates the trigger and buffer table when you enable a notification. The buffer table, which you specified when you configured the notification, holds the data selected by the trigger. There are no special size constraints for the buffer tables. The trigger monitors the database table you specified when you configured the notification and inserts data into the buffer table. When you disable a notification, the adapter drops the trigger and buffer table.When you enable a notification, the database trigger monitors the table and inserts the data into the buffer table. When the Integration Server invokes the notification, it retrieves the rows of data from the buffer table, publishes each row in the notifications publishable document, and then removes this row from the buffer table.After you enable these types of notifications, the trigger and buffer table remain in the database table when you: Shut down the Integration Server Disable the package containing the enabled notification Reload the package containing the enabled notification Suspend the notification.