On Fri, Dec 11, 2015 at 2:51 PM, Howard Chu <email@example.com> wrote:
> A DBI handle is simply a slot in an in-memory array. Read-only transactions are read-only with respect to the database.
That is fine with me. It was you who tried to explain the DBI handles in terms of 'transactional databases" . That explanation was problematic; copying your manner of speaking, one could say it was "utter nonsense".
Can you clarify just this point: in sample-mdb.txt, a DBI handle is opened in the first transaction, which commits, and is used the second transaction, which aborts. What happens with the DBI handle when the second transaction aborts? Does it stay valid or does it get closed?
> Your statement is preposterous. It is the same as saying that file handles in an operating system must stay open as long as files exist in a filesystem. Utter nonsense.
Oh, you mean I did not specify every little detail, such as "a DBI handle, once successfully created and persisted and not explicitly closed, ...". Sorry about that.
I appreciate the insightful explanation. There was another question in my message that you did not answer. I am copying it here for convenience.
Can you confirm that, with read-only transactions, the only difference between commit and abort is in the way the associated DBI handles are treated, and, specifically, that no observable effect on performance will occur? If that is so, a note in the documentation stating this would be very helpful.
 Howard Chu: "Transactional databases are very simple"