So, it's time for the answers.
The question 1 is the easiest:
Did you answer all these questions correctly? I guess so, since they are very easy.
If you are interested, consider to visit Firebird 2013 Tour seminar "All About Transactions" in Siegburg, Germany, November 22, 2013.
The question 1 is the easiest:
1. In some transaction there were 3 inserts made. The third INSERT raises exception. Is it possible to commit this transaction?
[ ] yes, [ ] no
Answer is Yes, of course. An ability to commit or rollback transaction does not depend on insert operations which were performed in the frame of transaction. Of course, usually application logic is built in the way to commit only successful set of operations, but it's not a rule.
The second question is a bit more tricky:
2. In some table there were 10 records. 3 simultaneous transactions were started and then in each transaction 1 record was inserted. In transaction 3 query SELECT COUNT(*) FROM Table was executed. The result will be:
[ ] 10, [ ] 11, [ ] 12, [ ] 13
In this question you need to take an account that transactions are not committed. As you know, all changes in the frames of non-committed transaction are visible only inside this transaction, so the answer will be 11.
The third question is devoted to the generators concept of Firebird engine.
3. Initially we have generator with name id, its value is 10. We have simultaneous transactions A and B. In A executed gen_id(id,1), in B gen_id(id,1). Then A was commited and B was rollbacked. What value is in id?
[ ] 10, [ ] 11, [ ]12
Generators (or sequences) work outside the frames of transactions. It means that commit or rollback of transactions does not affect the resulted value - i.e., generator ID will be increased both in A and B, and correct answer is 12.
Did you answer all these questions correctly? I guess so, since they are very easy.
There are more interesting topics related with transactions. For example, do you know that each database in Firebird has a limit of transactions which can be performed between backup/restore cycles? And, more interesting, that unused transactions occupy space in the database, which is released only after backup/restore, and there could be up to 700Mb of such space in the worst case?
If you are interested, consider to visit Firebird 2013 Tour seminar "All About Transactions" in Siegburg, Germany, November 22, 2013.