The following miscellaneous differences also exist between the BDB SQL interface and SQLite:
The BDB SQL interface does not support the IMMEDIATE
keyword (BEGIN IMMEDIATE
behaves just like BEGIN
).
There are differences in how the two products work in a concurrent application that will cause the BDB SQL interface to deadlock where SQLite would result in a different error. This is because the products use different locking paradigms. See Locking Notes for more information.
The BDB SQL does not call the busy callback when a session attempts
to operate the same database page that another session has locked.
It blocks instead. That is to say, the functions
sqlite3_busy_handler
and sqlite3_busy_timeout
are not effective in BDB SQL.
The BDB SQL does not support two phase commit across databases. Attaching to multiple databases can lead to inconsistency after recovery and undetected deadlocks when accessing multiple databases from concurrent transactions in different order. Hence, applications must ensure that they access databases in the same order in any transaction that spans multiple databases. Else, a deadlock can occur that causes threads to block, and the deadlock will not be detected by Berkeley DB.
In BDB SQL, when two sessions accessing the same database perform conflicting operations on the same page, one session will be blocked until the conflicting operations are resolved. For example,
Session 1:
dbsql> insert into a values (4); dbsql> begin; dbsql> insert into a values (5);
Session 2:
dbsql> select * from a;
What happens here is that Session 2 is blocked until Session 1 commits the transaction.
Session 1:
dbsql> commit;
Session 2:
dbsql> select * from a; 4 5
Under such situations in SQLite, operations poll instead of blocking, and a callback is used to determine whether to continue polling.
By default, you always only have a single database file when you use BDB SQL interface SQL, just as you do when you use SQLite. However, you can configure BDB SQL interface at compile time to create one BDB SQL interface database file for each SQL table that you create. How to perform this configuration is described in the Berkeley DB Installation and Build Guide.