[Oracle] Berkeley DB avoids "pit"

As an open source file database product, Berkeley DB has performance beyond Redis (this is what it says on the Internet). But it is a pity that I have no way to implement the AGPL open source agreement to the company's commercial level, but it is still possible to use it for fun. However, some of the following problems occurred during the trial process, and they are recorded here.

Question 1: Unable to open the database configuration

When opening the data, the following error will be thrown

com.sleepycat.je.DatabaseNotFoundException: (JE 6.4.9) Database stockDB not found.

The location of the throw is as follows:

insert image description here

Solution 1: This is because AllowCreate and Transactional are configured in EnvironmentConfig and DatabaseConfig must also be added accordingly, as shown in the figure below:

insert image description here

insert image description here

Question 2: Transaction exception during execution

Since the support for transaction processing has been set in the environment configuration, the following error will be thrown if the transaction configuration is not added when the operation is performed

insert image description here

Solution 2: Add a transaction processing method to each execution operation, and ensure that each method must be commit or rollback at the end (in fact, this can be uniformly processed through the aspect).

insert image description here

Question 3: An error is thrown when using the Truncate method to delete data

The following exception is thrown when using the Truncate method to delete data

com.sleepycat.je.LockTimeoutException: (JE 6.4.9) Lock expired. Locker 263025902 15_main_Txn: waited for lock on database=_jeNameMap LockAddr:1489069835 LSN=0x0/0x41a type=WRITE grant=WAIT_PROMOTION timeoutMillis=500 startTime=1483674798880 endTime=1483674799380 

Solution 3: This problem has troubled me for a long time. I searched many methods on the Internet and tried them to no avail. It is estimated that my understanding of BDB is not deep enough, and I will continue to follow up on this issue in the future. Currently, deleteByKey is used to delete data through transactions, which is equivalent to deleting data according to conditions.

Guess you like

Origin blog.csdn.net/kida_yuan/article/details/127506657